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EXECUTIVE  SUMMARY 


This  report  presents  the  results  of  the  Operational  Test  and  Evaluation  (OT&E)  of  the  Air  Route 
Surveillance  Radar  Model  4  (ARSR-4)  radar  system  at  Mt.  Laguna,  California.  The  tests  were 
conducted  from  May  23,  1994,  through  January  15,  1995  (using  multiple  software  builds),  and  from 
June  1,  1995,  through  August  11,  1995  (using  25MAY95  and  13JUN95  software  builds). 

OT&E  Integration  and  OT&E  Operational  tests  were  conducted  in  accordance  with  Federal  Aviation 
Administration  (FAA)  Order  1810.4B  to  verify  that  the  ARSR-4  is  operationally  suitable  and 
effective  and  can  meet  operational  requirements  when  integrated  into  the  Nation  Airspace  System 
(NAS).  OT&E  Integration  tested  the  ARSR-4  interfaces  with  other  NAS  subsystems  and  the  end-to- 
end  performance  of  the  ARSR-4  when  operated  in  NAS.  These  performance  tests  were  designed  to 
verify  that  the  ARSR-4  meets  both  NAS-SS-1000  and  ARSR-4  system  requirements.  OT&E 
Operational  tests  measured  the  suitability  and  effectiveness  of  the  ARSR-4  operating  in  NAS. 

Test  results  revealed  that  the  ARSR-4  performs  most  basic  surveillance  functions  well.  Improved 
ARSR-4  coverage  (when  compared  to  ARSR-3  coverage)  was  noted,  especially  in  areas  with  a 
history  of  poor  coverage.  Results  also  revealed  that  the  ARSR-4  can  process  and  provide  message 
outputs  for  a  steady  state  capacity  load  of  800  aircraft  returns  within  the  primary  radar  coverage  area 
in  the  Air  Traffic  Control  Beacon  Interrogator  (ATCBI)  configuration. 

Controller  comments  were  generally  favorable  although  several  problems  were  identified  during 
testing.  The  problems,  along  with  ACT-310  recommendations,  are  presented  in  the  following 
paragraphs.  The  “Current  Status”:  of  each  problem  is  presented  by  AND-440  and  reflects  the  efforts 
of  AND-440,  AOS-230,  and  Northrop  Grumman,  after  the  completion  of  OT&E,  to  resolve  the 
problems  that  were  identified. 

The  ARSR-4  at  Mt.  Laguna  had  a  significantly  higher  beacon  split  rate  than  the  ARSR-3.  The  higher 
split  rate  often  exceeded  Quick  Analysis  of  Radar  Sites  (QARS)  tolerances  which  were  used  to 
certify  the  radar  in  NAS.  The  cause  for  the  high  split  rate  at  Mt.  Laguna  should  be  identified  and 
corrected. 

Current  Status:  The  primary  cause  of  the  higher  beacon  split  rate  was  due  to  a  beacon  target  centroiding 
problem  that  was  corrected  in  the  5FEB96  software  build  for  the  ARSR-4.  The  installation  of  this  software 
and  the  additional  optimization  of  the  system  by  AOS-230  has  corrected  the  beacon  split  rate  to  a  level 
within  acceptable  tolerances.  The  ARSR-4  at  Mt.  Laguna  was  commissioned  on  3JUL96  following  the 
correction  of  this  problem  and  the  successful  retesting.  Through  the  utilization  of  this  new  software  and 
additional  optimization  procedures  developed  by  AOS-230,  13  additional  ARSR-4s  have  been  commissioned 
without  a  problem  with  the  beacon  split  rate. 

The  ARSR-4  did  not  perform  reliably  during  the  test  period.  The  number  of  critical  operational 
problems  encountered  was  excessive.  Several  significant  problems  remained  in  the  system  at  the 
conclusion  of  OT&E.  First,  a  “beacon  strobe”  problem  (the  reporting  of  all  beacon  targets  at  the 
same  azimuth)  was  encountered  during  the  certification  flight  check.  The  problem  was  identified  as  a 
serious  operational  problem  by  controllers.  Second,  the  ARSR-4  was  unable  to  automatically  restore 


xi 


a  faulted  or  standby  Central  Processing  Unit  (CPU)  to  on-line  status.  A  system  reset  (up  to  a  3- 
minute  outage)  was  needed  to  restore  faulted  CPUs.  These  known  problems  which  contribute  to 
poor  ARSR-4  reliability  should  be  addressed  immediately.  Additional  reliability  assessments  should 
be  made  after  the  system  has  run  for  a  time  with  a  controlled  hardware  and  software  configuration. 

Current  Status:  The  "beacon  strobe" problem  was  corrected  by  the  contractor  in  the  8AUG95  software  build 
and  that  correction  is  in  every  build  installed  in  all  ARSR-4  systems.  Subsequent  factory’  benchmark  and 
additional  site  testing  by  AOS-2 30  has  proven  that  this  fix  has  corrected  the  problem.  The  faulted/standby 
CPU  not  returning  to  the  mix  during  a  warmstart  was  corrected  tested  in  the  11SEP96  build.  In  addition 
following  the  completion  of  the  OT&E,  a  reliability  analysis  study  has  completed  demonstrating  that  the 
ARSR-4  system  has  met  the  reliability  requirements  in  the  contract.  The  study  included  failure  data  from  all 
of  the  ARSR-4  systems  installed  for  a  year  after  the  tenth  system  was  installed  and  included  26  systems. 
Further  analysis  of  the  commissioned  ARSR-4 s  (14  to  date)  demonstrate  that  the  ARSR-4  system  is 
exceeding  the  availability  requirements  of  the  NAS. 

Operational  problems  were  introduced  into  the  ARSR-4  when  new  software  builds  were  installed 
during  OT&E.  This  points  to  insufficient  software  testing  at  the  factory.  The  ineffective  software 
testing  had  an  adverse  effect  on  ARSR-4  reliability  during  OT&E.  New  software  builds  should  be 
fully  tested  at  the  factory  and  at  a  test  site  prior  to  reaching  the  end  users  in  the  field. 

Current  Status  :  Based  on  this  recommendation,  a  software  configuration  control  and  testing  plan  was 
developed  in  cooperation  with  ACT-310,  AOS-230,  and  AND-440  to  insure  that  no  new  problems  were 
introduced  as  new  software  builds  were  produced  by  the  contractor.  The  plan  includes  a  review  of  the 
proposed  changes  and  factory  benchmark  testing  plus  testing  at  other  installed  sites  prior  to  installation  in 
an  operational  or  commissioned  system.  The  plan  has  been  implemented  and  has  been  used  on  all  new 
software  builds. 

The  ARSR-4,  as  configured  at  Mt.  Laguna,  did  not  consistently  recover  from  a  short-term  power 
loss  (less  than  15  seconds).  The  ARSR-4  should  be  operated  with  an  Uninterruptable  Power  Supply 
(UPS)  in  addition  to  a  reliable  backup  engine  generator  in  order  to  avoid  most  of  the  power  related 
problems  described  in  this  report. 

Current  Status:  The  contractor  has  made  software  changes,  hardware  corrections,  and  maintenance 
procedural  changes  in  an  effort  to  insure  that  the  ARSR-4  meets  the  requirements  for  recovery  from  short¬ 
term  power  loss.  Due  to  the  importance  of  this  issue,  AND-440  agreed  with  this  recommendation  and  as 
part  of  the  ARSR-4  Deployment  Decision,  all  ARSR-4s  will  be  installed  and  operated  with  an  UPS  in 
addition  to  a  reliable  backup  engine  generator  prior  to  system  commissioning  into  the  NAS.  AND-440  has 
provided  the  funding  for  the  UPS  systems  at  all  ARSR-4s. 

ARSR-4  Built-In  Test  (BIT)  and  Fault  Isolation  Test  (FIT)  features  detected  and  isolated  most  of  the 
faults  injected  into  the  system  during  the  test  period.  However,  serious  failures  on  several  boards  in 
the  Data  Processor  were  not  automatically  detected.  This  indicates  that  not  all  possible  faults  were 
injected  into  the  system  during  testing.  The  level  of  BIT/FIT  effectiveness  in  detecting/isolating 
problems  with  faulted  boards  is  unknown.  In  addition,  BIT  does  not  monitor  the  status  of  backup 
battery  voltages  in  the  Signal  Processor  and  Data  Processor.  Data  can  be  lost  to  the  user  if  the 
ARSR-4  experiences  a  power  loss  while  the  backup  batteries  are  faulty  or  uncharged.  ARSR-4 
BIT/FIT  should  not  be  used  as  the  only  means  to  maintain  the  system.  An  alternate  plan  (such  as 
troubleshooting  flowcharts)  should  be  developed  to  assist  the  radar  technician  in  troubleshooting 
problems  when  BIT/FIT  do  not  detect  or  isolate  faults. 
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Current  Status:  The  contractor  has  developed  and  delivered  a  generic  trouble  shooting  procedure  for 
failures  in  the  system  that  have  not  been  detected  and  isolated  by  BIT/FIT.  In  addition,  the  contractor  has 
delivered  a  list  of  the  possible  2  percent  of  items  in  the  ARSR-4  that  cannot  be  detected  by  BIT.  These 
documents  have  been  delivered  to  AOS-230 for  review  and  comment.  These  two  documents  and  the  ARSR-4 
technical  instruction  books  on  site  will  provide  enough  information  to  perform  corrective  maintenance  on 
the  system  for  the  Independent  Operational  Test  and  Evaluation  (lOT&E)  period.  All  of  the  documents 
identified  above  are  being  reviewed  and  redlined  to  optimize  the  corrective  maintenance  of  the  system. 

These  procedures  have  been  presented  to  AOS-230 for  concurrence.  The  contractor  has  continued  to  make 
improvements  for  those  faults  not  detected  in  the  lOT&E  baseline  software  build,  to  fine  tune  the  critical 
parameters  which  govern  the  BIT's  capability  to  detect  failures  for  specific  areas  of  the  ARSR-4  identified  as 
problems  during  the  ACT/AOS  testing  at  Mt.  Laguna.  Those  changes  have  been  included  in  the  11SEP96 
software  build  which  has  completed  the  benchmark  and first  site  field  testing  and  is  installed  in  one 
commissioned  ARSR-4. 

The  available  spare  memory  in  the  ARSR-4  at  the  end  of  OT&E  will  not  be  sufficient  to  support 
future  system  corrections  or  upgrades.  The  spare  memory  should  be  increased  to  support  system 
upgrades,  future  system  expansion,  or  corrections  for  any  future  problems. 

Current  Status:  A  contract  modification  was  executed  in  December  of 1996,  and  the  critical  design  review 
held  on  March  19,  1997,  for  the  contractor  to  develop  a  prototype  modification  to  the  ARSR-4  system 
design  to  add  25  percent  spare  memory.  The  modifications  will  include  hardware  and  software  upgrades  to 
be  completed  by  November  1997.  Following  successful  testing  of  the  prototype  another  contract 
modification  with  FY98  money  will  be  executed  to  install  the  spare  memory  increase  in  all  44  ARSR-4s. 

The  ARSR-4  met  the  2.2-square  meter  primary  range  and  azimuth  resolution  requirements  (50 
percent  requirement).  However,  the  ARSR-4  failed  the  10-square  meter  primary  range  and  azimuth 
resolution  tests  (a  more  stringent,  90-percent  requirement).  Test  results  revealed  a  resolution  “hole” 
which  indicates  a  problem  in  the  ARSR-4  resolution  algorithms.  The  operational  significance  of  the 
range  resolution  hole  (between  1/8  nautical  mile  (nm)  and  1/4  nm)  should  be  evaluated  by  Air  Traffic 
(AT)  personnel. 

Current  Status:  The  ARSR-4's  search  resolution  performance  will  not  have  an  effect  on  the  operational 
performance  of  the  FAA  or  Air  Force,  and  their  ability  to  maintain  the  required  operational  separation 
between  aircraft.  This  issue  has  been  discussed  in  detail  with  ATR-1 10  and  based  on  those  discussions  and 
a  review  ofSR-1000,  a  decision  has  been  made  that  the  search  resolution  problems  seen  during  the  OT&E 
testing  will  not  have  an  operational  impact  in  the  enroute  environment.  This  has  been  confirmed  by  the  fact 
that  no  operational  issues  have  been  seen  by  the  AT  community  relating  to  the  search  resolution  from  the 
data  utilized  from  the  14  commissioned  ARSR-4s.  The  Air  Force  conducted  additional  resolution  flight  tests 
for  the  ARSR-4  to  verify  the  separate  Air  Force  requirements.  The  Air  Force  requirements  use  two  2. 2- 
square  meter  targets  and  the  resolution  requirement  is  set  at  50  percent.  The  ARSR-4  exceeded  the 
requirements  for  the  Air  Force. 

The  ARSR-4  weather  detection  and  reporting  capability  was  not  fiilly  evaluated  at  Mt.  Laguna  due 
to  the  unavailability  of  significant  weather  in  the  area.  However,  one  problem  was  identified  in  the 
weather  presentation  on  the  controllers;  displays  at  the  Los  Angeles  Center.  The  Direct  Access 
Radar  Channel  (DARC)  system  displays  ARSR-4  weather  information  differently  than  the  HOST. 
The  inconsistent  weather  processing  between  Air  Route  Traffic  Control  Center  (ARTCC)  computers 
is  not  suitable  for  air  traffic  control  (ATC).  DARC  weather  processing  should  be  corrected  so  that 
consistent  weather  information  is  reported  to  the  controller  when  the  backup  system  is  switched  on¬ 
line. 
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Current  Status:  Two  problems  contributed  to  this  problem.  The  first  was  that  NAS  Change  Proposal  (NCP) 
TR230-CPF-022  modified  the  display  of  weather  in  the  NAS  so  that  high  level  weather  is  now  displayed  in 
addition  to  the  medium  and  low  level  weather.  Previously,  NAS  discarded  high  level  weather.  The  DARC 
software  at  the  time  of  the  OT&E  was  not  modified  to  display  the  high  level  weather.  Therefore,  the  ARSR-4 
weather  data  was  displayed  differently  on  the  NAS  and  DARC  systems.  The  controllers  saw  the  same 
symbols  on  both  systems  but  the  symbols  will  have  different  meanings.  The  DARC  software  was  modified  to 
correspond  to  the  requirements  of  the  NCP,  but  the  changes  were  not  implemented  prior  to  the  completion  of 
the  OT&E.  The  DARC  software  changes  were  implemented  prior  to  the  commissioning  of  the  ARSR-4  at  Mt. 
Laguna  in  June  of 1996. 

A  second  problem  dealt  with  the  weather  data  being  sent  from  the  ARSR-4  system  at  a  rate  higher  than  the 
HOST  system  limitation  required  by  the  Computer  Display  Channel  (CDC)  but  the  DARC  could  process  the 
data  at  the  higher  rate.  Sometimes  weather  data  from  the  ARSR-4  was  displayed  by  the  DARC  and  not 
through  the  HOST  processing  path.  Changes  to  the  ARSR-4  software  were  required  to  correct  the  problem'. 
This  software  correction  was  completed  by  the  contractor,  implemented  in  the  5FEB96  software  build,  and 
passed  the  benchmark  testing  prior  to  installation  in  the  ARSR-4  systems.  This  change  is  included  in  the 
software  in  all  commissioned  ARSR-4s. 

The  ARSR-4  design  allows  the  system  to  be  optimized,  adapted  to  site  conditions,  and  certified. 
However,  during  OT&E,  the  ARSR-4  output  false  weather  to  the  user  when  anomalous  propagation 
(AP)  conditions  were  prevalent.  This  indicates  a  limitation  in  the  ability  of  the  ARSR-4  to 
automatically  adapt  to  some  changing  environmental  conditions.  The  impact  of  false  weather  caused 
by  AP  should  be  evaluated  at  each  site.  If  the  false  weather  is  more  severe  at  other  locations,  causing 
operational  problems,  steps  (either  through  procedural  changes  or  redesign)  should  be  taken  to 
ensure  that  the  ARSR-4  can  automatically  adapt  to  these  environmental  conditions. 

Current  Status:  To  address  this  issue  an  AP  Working  Group  has  been  formed  with  AOS-230  as  the  lead, 
and  members  from  Air  Force  FADES,  ARSR-4  contractor,  regional  representatives,  MITRE,  and  AND-440. 
The  purpose  of  the  group  was  to  analyze  the  problem  in  further  detail  now  that  there  are  several  ARSR-4s  in 
operation  and  develop  a  solution  that  would  be  tailored  to  the  specific  AP  conditions  of  a  particular  site. 

The  intent  is  to  maximize  the  capabilities  already  built  into  the  current  ARSR-4  design  prior  to  developing 
design  modifications  that  will  be  implemented  by  AOS-2 30.  The  work  is  still  in  progress. 

The  ARSR-4  to  ARTCC  interface  operates  effectively.  The  ARSR-4,  however,  will  not  interface 
effectively  with  the  Mode  Select  Beacon  System  (Mode  S)  or  the  Radar  Remote  Weather  Display 
System  (RRWDS).  Proper  operation  of  these  interfaces  requires  further  design  changes  to  the 
ARSR-4.  Additional  testing  is  recommended  for  these  interfaces  after  the  problems  are  corrected. 

Current  Status:  A  contract  modification  has  been  executed  with  the  Mode  S  contract  to  complete  the 
development  of  the  ARSR-4  to  Mode  S  interface.  Based  on  the  proposed  design  of  the  interface  only  a  small 
hardware  modification  to  the  ARSR-4  will  be  required.  Significant  changes  to  the  Mode  S  system  will  be 
required.  The  prototype  design  will  completed  by  December  1997.  Currently  there  are  no  ARSR-4s  planned 
to  be  installed  with  a  Mode  S. 

AOS-2 30  has  volunteered  to  develop  and  implement  the  correction  to  the  RRWDS  interface  problems.  The 
changes  were  made  on  the  RRWDS  side  of  the  interface  and  was  implemented  the  week  of  August  14,  1995, 
on  the  Mt.  Laguna  system,  and  verified  during  the  lOT&E period.  The  modifications  to  the  other  RRWDS 
will  be  implemented  by  AOS-230.  AOS-230  will  fidly  test  the  modification  to  the  interface  prior  to  its 
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implementation.  The  implementation  of  these  modifications  at  all  ARSR-4/RRWDS  sites  will  occur  following 
the  installation  of  the  ARSR-4s.  Currently,  the  RRWDS  is  not  critical  to  the  operation  of  the  FAA,  Air  Force, 
or  Customs  Service  and  is  not  a  certifiable  piece  of  equipment  but  provides  data  to  the  National  Weather 
Service(NWS). 
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INTRODUCTION. 


1.1  PURPOSE. 

This  report  presents  the  results  of  the  Operational  Test  and  Evaluation  (OT«&E)  of  the  Air  Route 
Surveillance  Radar  Model  4  (ARSR-4)  radar  system.  OT&E  Integration  and  Operational  tests 
were  conducted  in  accordance  with  Federal  Aviation  Administration  (FAA)  Order  1810.4B  to 
verify  that  the  ARSR-4  is  operationally  suitable  and  effective  and  can  meet  operational 
requirements  when  integrated  into  the  National  Airspace  System  (NAS). 

1.2  SCOPE. 

This  report  discusses  the  results  of  the  OTifeE  Integration  and  Operational  tests  performed  on  the 
ARSR-4  from  May  23,  1994,  through  August  14,  1995.  The  first  phase  of  OT&E  was  conducted 
on  the  ARSR-4  at  Mt.  Laguna,  California,  from  May  23,  1994,  through  November  1,  1994.  The 
discovery  of  significant  problems  during  that  period  led  to  regression  testing  after  the  identified 
problems  w'ere  fixed.  OT&E  regression  tests  were  conducted  from  June  5,  1995,  through  August 
14,  1995. 

2.  DOCUMENTS. 

FAA-E-2763b 

NAS-SS-1000 

NAS-MD-110 


ORDER  1810.4B 


ARSR-4  Radar  System  Specification,  May  6,1988 

NAS  System  Specification,  Vol.  I,  II,  III,  and  V,  December  1986 

Test  and  Evaluation  Terms  and  Definitions  for  the  NAS, 

March  27,1987 

FAA  NAS  Test  and  Evaluation  Policy,  October  17,  1991 
ARSR-4  Interface  Control  Documents 


ARSR-4  Operational  Test  and  Evaluation  Plan,  June  14,  1994. 

ARSR-4  Test  Procedures,  February  27,  1990 

ARSR-4  Technical  Instruction  Books,  Westinghouse  Electric 
Corporation,  Baltimore,  Maryland 

3,  SYSTEM  DESCRIPTION. 

3.1  MISSION  REVIEW. 

The  ARSR-4  is  a  three-dimensional,  state-of-the-art,  all  solid-state  radar  system  being  jointly 
procured  by  the  FAA  and  United  States  Air  Force  (USAF).  The  ARSR-4  system  will  replace 
existing  ARSR-1  and  ARSR-2  radar  systems  and  establish  radar  coverage  at  new  locations. 
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The  primary  mission  of  the  ARSR-4  is  to  provide  high  quality,  primary  digital  radar  data  on 
aircraft  positions  to  the  Air  Route  Traffic  Control  Center  (ARTCC)  and  to  the  Sector  Operations 
Control  Center  (SOCC)  and  Fleet  Area  Control  Surveillance  Facility  (FACSFAC). 

When  interfaced  with  an  Air  Traffic  Control  Beacon  Interrogator  (ATCBI)  or  Mode  Select 
Beacon  System  (Mode  S),  the  ARSR-4  will  also  provide  secondary  radar  (beacon)  data  on 
transponder  equipped  aircraft. 

The  secondary  mission  of  the  ARSR-4  is  to  detect  and  report  weather  within  the  coverage  area  in 
National  Weather  Service  (NWS)  six  level  format. 

Detailed  operational  characteristics  for  the  ARSR-4  are  defined  in  the  FAA  operational 
requirements  document  (ORD).  The  key  operational  characteristics  are: 

a.  Coverage.  The  coverage  volume  of  the  ARSR-4  extends  from  5  to  250  nautical  miles 
(nm)  for  360°  and  from  the  radar  line  of  site  (RLS)  to  100,000  feet  above  ground  level  (AGL)  to 
30°  in  elevation.  A  lookdown  beam  detects  targets  to  -7°  below  the  radar  horizon.  The  ARSR-4 
must  detect  a  2.2  square  meter  radar  cross  section  (RCS)  target  within  this  volume  at  any  range 
less  than  200  nm  with  a  probability  of  80  percent  or  greater. 

b.  False  Reports.  The  ARSR-4  is  required  to  operate  in  all  clutter  environments  with 
minimal  degradation  in  detection  and  no  more  than  194  false  target  reports  per  scan. 

c.  Positional  Accuracy.  The  ARSR-4  required  primary  radar  positional  accuracy  is  1/16  nm 
route  mean  squared  (rms)  in  range,  2  Azimuth  Change  Pulses  (ACPs)  rms  in  azimuth  and  3000 
feet  rms  in  height  (within  200  nm).  The  required  beacon  positional  accuracy  is  1/32  nm  rms  in 
range  for  stationary  targets,  1/16  nm  rms  in  range  for  moving  targets,  2  ACPs  RMS  in  azimuth, 
and  within  125  feet  in  height  with  95  percent  probability. 

d.  Resolution.  The  ARSR-4  must  resolve  two  closely  spaced  aircraft  at  least  90  percent  of 
the  time  when  separated  by  1/8  nm  or  greater  in  range  and/or  2.0°  or  greater  in  azimuth. 

e.  Weather  Detection.  The  ARSR-4  will  detect  five  weather  levels  within  the  coverage 
volume  with  minimal  degradation  from  ground  clutter  and  second  time  around  weather. 

f  Remote  Monitoring.  The  ARSR-4  will  provide  remote  monitoring,  control,  and 
diagnostic  capability  through  Remote  Maintenance  Monitoring  System  (RMMS). 

g-  Operational  Availability.  The  ARSR-4  operational  availability  will  be  at  least  0.99742. 

The  ARSR-4  will  be  operable  and  maintainable  with  the  currently  available  work  force  and  skill 
levels  and  require  minimal  periodic  maintenance  visits. 

h.  Site  Adaptation  and  Optimization.  The  ARSR-4  will  be  site  adaptable  using  a  well  defined 
and  efficient  procedure.  ARSR-4  will  require  minimal  readjustment  or  parameter  optimization  to 
compensate  for  environmental  and  seasonal  changes. 
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3,2  TEST  SYSTEM  CONFIGURATION. 

The  ARSR-4  was  collocated  with  an  ARSR-3  radar  at  Mt.  Laguna  during  OT&E.  To  avoid 
mutual  interference  between  radars,  the  ARSR-3  transmitter  was  blanked  in  the  direction  of  the 
ARSR-4  and  the  ARSR-4  transmitter  was  blanked  in  the  direction  of  the  ARSR-3  (from  326°  to 
360°  in  azimuth). 

The  ARSR-3  operated  in  simplex  mode  on  channel  B  to  avoid  interfering  with  ARSR-4  operation. 
The  ARSR-3  operated  in  diplex  only  when  requested  by  controllers  (usually  to  provide  better 
ARSR-3  weather  products).  No  ARSR-4  testing  could  be  conducted  with  the  ARSR-3  in  diplex 
due  to  the  severe  interference. 

A  beacon  blanker  was  installed  on  the  ATCBI-5  to  interrupt  triggers  to  the  ARSR-4  in  the  area 
from  330°  to  360°,  effectively  blanking  beacon  operation  in  that  region.  Later,  a  military  map  was 
configured  in  the  ARSR-4  to  accomplish  the  same  task. 

The  ARSR-4  at  Mt.  Laguna  was  configured  with  no  lookdown  capability.  The  ARSR-4  operated 
in  Variable  Interpulse  Period  (VIPl)  mode  for  most  of  the  tests.  The  Auto  Reconfiguration  and 
Auto  Transmit  features  were  enabled  for  most  tests. 

Numerous  software  builds  were  installed  in  the  Mt.  Laguna  ARSR-4  during  testing.  Those  builds 
are  listed  in  table  3.2-1.  The  first  phase  of  OT&E  began  on  May  18,  1994,  using  the  05MAY94 
software  build  and  extended  through  November  1,  1994,  using  the  06SEP94  build.  Those  builds 
installed  between  November  1,  1994,  and  May  16,  1994,  were  interim  builds  which  addressed 
problems  identified  during  the  first  phase  of  OT&E. 

OT&E  regression  tests  were  started  on  the  25MAY95  software  build.  However,  problems 
identified  in  that  build  required  further  fixes.  On  July  8,  1995,  the  13  JUN95  build,  which 
contained  the  required  fixes,  was  installed  and  used  for  the  remainder  of  OT&E. 
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TABLE  3.2-1 .  SOFTWARE  BUILDS  INSTALLED  DURING  OT&E 


Software  Build 

Installation  Date 

03MAY94 

May  18, 1994 

28JUNW 

M24, 1994 

1MBG94 

Sep  02, 1994 

06SEP94 

Oct  11, 1994 

280CT94 

Nov  01, 1994 

0.3NOV94 

Nov  13,  1994 

22NOV94 

Dec  08,  1994 

21DEC94 

Jan  30,  1995 

23FEB95 

Mar  08,  1995 

07MAR95 

Mar  13,  1995 

28MAR95 

Apr  06,  1995 

07APR95 

Apr  08,  1995 

17APR95 

Apr  19,  1995 

05MAY95 

May  09,  1995 

12MAY95 

May  16,  1995 

25MAY95 

May  26, 1995 

13JUN95 

Jill  08,  1995 

3,3  INTERFACES. 

The  ARSR-4  will  interface  with  the  existing  and  planned  NAS  equipment  listed  in  table  3.3-1. 

This  table  indicates  whether  the  actual  interfaces  were  available  for  test,  whether  the  interface  was 
simulated,  or  whether  the  testing  was  deferred  due  to  unavailability  of  equipment. 

TABLE  3.3-1.  ARSR-4  INTERFACES 


Interface 

OT&E  Status 

ATCBI-5 

Actual 

Mode  S 

Simulated/Deferred 

RRWDS 

Actual 

ARTCC/HOST/DARC 

Actual 

En  Route  Automated  Radar  Tracking  System 

Deferred 

(EARTS)  and  Microprocessor  EARTS 
(MicroEARTS) 

SOCC/FACSFAC 

Actual 

RMMS 

Actual 

As  shown  in  table  3.3-1,  the  tests  performed  on  each  interface  except  the  Mode  S,  Enroute 
Automated  Radar  Tracking  System  (EARTS),  and  the  Microprocessor-based  Enroute  Automated 
Radar  Tracking  System  (MicroEARTS)  were  performed  with  the  actual  equipment.  Because  the 
Mode  S  was  not  available  at  Mt.  Laguna  during  OT&E,  tests  of  the  interface  were  limited  to 
document  review  and  ARSR-4  status  message  inspection  using  a  protocol  analyzer  to  simulate  the 
Mode  S.  Since  these  tests  did  not  test  the  end-to-end  performance  of  the  interface,  the  majority  of 
ARSR-4/Mode  S  integration  tests  were  deferred  until  the  Mode  S  is  available. 
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Tests  of  the  ARSR-4  to  EARTS  and  ARSR-4  to  MicroEARTS  interfaces  have  not  yet  been 
performed  due  to  the  unavailability  of  the  equipment  at  the  Los  Angeles  ARTCC.  The  first 
ARSR-4  site  scheduled  to  interface  with  a  MicroEARTS  is  in  Mt.  Santa  Rosa,  Guam.  The  first 
ARSR-4  site  scheduled  to  interface  with  an  EARTS  is  in  Mt.  Kaala,  HI.  These  interface  tests  will 
be  deferred  until  the  ARSR-4  is  installed  at  each  of  these  sites. 

3,4  OT&E  DESCRIPTION. 

OT&E  was  divided  into  Integration,  Operational,  and  Shakedown  tests.  OT&E  Integration  tests 
evaluate  the  NAS  end-to-end  performance  with  the  ARSR-4  included  as  part  of  NAS.  These  tests 
include  the  ARSR-4  interfaces  and  specification  related  performance  tests. 

OT&E  Operational  tests  evaluate  the  effectiveness  and  suitability  of  the  ARSR-4  when  integrated 
into  NAS.  User  input  is  provided  by  air  traffic  controllers  and  the  reliability,  maintainability,  and 
availability  of  the  ARSR-4  is  assessed. 

3.4.1  Test  Schedule  and  Locations. 

OT&E  Operational  and  Integration  tests  were  performed  at  the  Mt.  Laguna,  CA,  radar  site  and  at 
the  Los  Angeles  ARTCC. 

Mt  Laguna  was  chosen  as  the  test  site  due  to  a  challenging  environment  with  a  combination  of 
land  (mountains)  and  sea  clutter.  The  site  is  located  approximately  50  miles  east  of  San  Diego  and 
has  an  elevation  of  6238  feet  above  Mean  Sea  Level  (MSL).  The  ARSR-4  will  replace  the  ARSR- 
3  radar  presently  operating  at  Mt.  Laguna. 

The  Mt.  Laguna  ARSR-4  transmitted  radar  data  to  the  Los  Angeles  ARTCC  located  in  Palmdale, 
CA.  The  ARSR-4  was  adapted  as  a  new  radar  which  allowed  the  data  to  be  switched  into  the 
HOST  computer  system  or  Direct  Access  Radar  Channel  (DARC). 

3.4.2  Participants. 

ACT-310  provided  overall  management  for  the  test  program  through  the  Associate  Program 
Manager  for  Test  (APMT).  In  addition,  ACT-310  personnel  conducted  OT&E  Integration  and 
OT&E  Operational  tests  with  support  from  Western  Pacific  region,  the  Los  Angeles  ARTCC,  and 
Mt.  Laguna  site  personnel.  AOS-230  and  the  Air  Force’s  84th  Radar  Evaluation  Squadron 
(RADES)  worked  together  to  optimize  the  Mt.  Laguna  ARSR-4.  In  addition,  both  organizations 
worked  together  during  the  OT&E  Shakedown  phase  of  testing.  ACT-330  conducted  OT&E 
Integration  tests  on  the  ARSR-4  to  RMMS.  Table  3. 4. 2-1  lists  the  organizations  involved  in 
OT&E  along  with  the  responsibility  of  each  organization. 

TABLE  3.4.2-L  ARSR-4  OT&E  RESPONSIBILITIES 


_ Organization 

FAA  Technical  Center,  ACT-3 10 

FAA  Aeronautical  Center,  AOS-230 
FAA  Technical  Center,  ACT-330 
84th  Radar  Evaluation  Squadron 


_ Responsibility _ 

OT&E  Integration  and  OT&E 
Operational 

OT&E  Shakedown  and  Optimization 
RMS  and  RMMS  testing 
Optimization  and  OT&E  shakedown 
support _ 
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3.4.3  Test  Obiectives/Criteria. 

OT&E  verifies  that  the  ARSR-4  meets  all  operational  requirements,  resolves  all  critical  issues, 
and  integrates  effectively  with  other  components  in  NAS.  From  the  operational  requirements,  the 
following  major  operational  issues  were  identified  for  test; 

a.  Coverage  Does  the  ARSR-4  provide  the  air  traffic  controller  with  suitable  primary  and 
secondary  radar  data  within  the  required  coverage  volume  which  allows  the  controller  to  monitor 
flight  progress,  identify  violations  of  airspace  restrictions  and  potential  conflict  situations,  and 
maintain  separation  standards? 

b.  False  Alarm  Rate  Does  the  number  and  distribution  of  false  reports  from  the  ARSR-4 
allow  reliable  aircraft  detection,  identification,  and  tracking  consistent  with  the  air  traffic  control 
(ATC)  mission  and  airspace  safety  requirements? 

c.  Site  Adaptation  and  Optimization  Does  the  system  design  and  procedures  allow  the  radar 
system  to  be  optimized,  adapted  to  site  conditions,  and  certified  in  a  reasonable  time  by  available 
maintenance  personnel?  Is  the  time  before  reoptimization  consistent  with  the  maintenance 
philosophy? 

d.  Aircraft  Separation  Does  the  radar  detect  closely  spaced  aircraft  with  sufficient  reliability 
to  allow  the  controller  to  maintain  separation  standards? 

e.  Reliability,  Maintainability,  and  Availability  Is  the  reliability,  maintainability,  and  availability 
of  the  ARSR-4  suitable  for  incorporation  into  the  NAS  when  used  in  an  operational  environment 
with  the  available  resources,  logistics  plan,  maintenance  procedures,  and  personnel? 

f  NAS  Interoperability  Does  the  ARSR-4  operate  effectively  within  the  NAS  including  the 
following  issues: 

1 .  Compatibility  with  other  site  equipment, 

2.  Equipment  interface, 

3.  Data  and  signal  quality, 

4.  Data  capacity  and  delay? 

g.  Primary  Power  Requirements  Does  the  system  operate  within  the  voltage  tolerance 
envelope  encountered  on  site? 

h.  Weather  Detection  and  Display  Does  the  ARSR-4  provide  accurate  and  reliable  weather 
data  suitable  for  safe  aircraft  routing  by  ATC? 

i.  Safety  Is  the  ARSR-4  safe  to  operate? 
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TEST  AND  EVALUATION. 


4. 1  QT&E  INTEGRATION  TESTS. 

OT&E  Integration  measured  the  end-to-end  performance  of  the  ARSR-4  in  NAS.  Performance 
and  interface  capabilities  were  tested  to  ensure  that  the  ARSR-4  provides  accurate  data  in  a 
reliable  manner  to  the  end  user. 

4.1.1  Surveillance  to  ART CC . 

These  tests  verify  that  the  ARSR-4  reliably  transmits  data  in  the  proper  format  to  the  ARTCC 
with  sufficient  built-in  test  capability  to  detect  degraded  performance. 

4. 1  ■  1 . 1  User  Port  Operation. 

Purpose 

Ensure  that  the  ARSR-4  can  physically  and  functionally  interface  to  user  modems. 

Test  Objectives 

a.  Verify  that  the  ARSR-4  user  ports  can  be  configured  to  support  individual  user 
requirements. 

b.  Verify  that  five  of  the  ports  are  adjustable  to  EIA-RS-232  and/or  EIA-RS-530,  nine  are 
EIA-RS-232  compatible,  and  six  (military  ports)  are  EIA-RS-530  compatible. 

c.  Verify  that  the  clock  and  data  electrical  characteristics  and  timing  are  in  compliance  with 
EIA-RS-232  and  EIA-RS-530  standards  at  varying  signaling  rates. 

d.  Verify  that  there  is  sufficient  redundancy  in  the  ARSR-4  to  reconfigure  standby  Serial 
Input/Output  (SIO)  ports  to  on-line  when  a  communications  failure  is  encountered. 

Test  Description 

The  ARSR-4  communicates  with  the  modems  via  the  Input/Output  (I/O)  subsystem  in  the  data 
processor.  Eight  SIO  boards,  each  containing  four  serial  ports,  provide  data  to  the  user  (a  ninth 
SIO  board  is  used  as  a  spare).  Of  the  four  serial  ports,  port  0  is  software  configurable  to  RS-232 
or  RS-530/RS-422,  port  1  is  configured  for  RS-232  operation,  and  ports  2  and  3  are  configured 
for  RS-530/RS-422  operation. 

Table  4. 1 . 1 . 1  - 1  shows  the  I/O  subsystem  configuration  for  Mt.  Laguna.  The  table  includes  the 
SIO  board,  serial  port,  electrical  protocol,  and  physical  jack  assignments  in  the  Radar  Cable 
Junction  Box  (RCJB)  for  each  user  port.  As  seen  in  the  table,  the  ARSR-4  provides  20  user  ports 
(AF1-AF6,  andPl-P14). 
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TABLE  4.1. 1.1-1.  ARSR-4  COMMUNICATIONS  PORT  ASSIGNMENTS 


SIO 

Board 

Serial  Port . 

Electrical 

Protocol 

RCJB 

Jack 

AFl 

1 

3 

RS-530 

AF2 

3 

3 

RS-530 

AF3 

4 

3 

RS-530 

J30 

AF4 

5 

3 

RS-530 

J35 

AF5 

6 

3 

RS-530 

J36 

AF6 

8 

3 

RS-530 

J37 

PI 

1 

0 

RS-232 

J48 

1 

0 

RS-530 

J49 

P2. 

2 

0 

RS-232 

J50 

2 

0 

RS-530 

J51 

P3 

6 

0 

RS-232 

J55 

6 

0 

RS-530 

J56 

P4 

4 

0 

RS-232 

J57 

4 

0 

RS-530 

J58 

P5 

5 

0 

RS-232 

J69 

5 

0 

RS-530 

J70 

P6 

3 

1 

RS-232 

P7 

2 

1 

RS-232 

P8 

4 

1 

RS-232 

P9 

5 

1 

RS-232 

PIO 

3 

0 

RS-232 

Pll 

1 

1 

RS-232 

J79 

P12 

6 

1 

RS-232 

J90 

P13 

7 

1 

RS-232 

J91 

P14 

8 

1 

RS-232 

J92 

Pulse  characteristics  measurements  were  made  at  the  jacks  in  the  RCJB  using  an  Hewlett  Packard 
545  lOA  oscilloscope.  Channel  one  of  the  oscilloscope  was  used  to  measure  data  signal 
characteristics  (i.e.,  voltages,  pulse  widths,  rise  times,  fall  times)  while  channel  two  measured 
clock  signal  characteristics.  The  two  channels  were  compared  to  ensure  that  data  levels 
transitioned  on  the  correct  edge  of  the  clock  and  that  setup  and  hold  times  were  being  observed. 
The  measurements  were  repeated  for  both  RS-232  and  RS-530  ports  operating  at  various  baud 
rates. 

Action  was  taken  at  the  local  display  console  (LDC)/Remote  Monitoring  Subsystem  (RMS)  to 
configure  from  one  to  four  user  ports  for  each  user.  In  addition,  the  spare  SIO  board  was 
switched  on-line  to  verify  redundant  operation. 

Results 

The  ARSR-4  provides  sufficient  flexibility  to  configure  the  communications  ports  to  support  FAA 
and  USAF  requirements.  The  ARSR-4  provides  20  user  ports  to  interface  with  up  to  20  users. 

Up  to  four  ports  can  be  assigned  to  any  individual  user.  Six  user  ports  are  dedicated  to  military 
users  and  communicate  via  the  RS-530  standard.  The  remaining  14  user  ports  are  joint 
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FAA/Military  ports  and  are  configured  for  RS-232.  Five  of  the  14  joint  user  ports  can  be 
software  configured  for  RS-232  or  RS-530  operation. 

Oscilloscope  measurements  showed  that  the  clock  and  data  voltages,  pulse  widths,  and  rise  and 
fall  times  were  in  compliance  with  EIA-RS-232  or  EIA-RS-530  standards  at  the  various  available 
baud  rates.  Data  transitioned  on  the  correct  edge  of  the  clock. 

The  spare  SIO  board  can  be  switched  on-line  via  RMS  control  of  the  A/B  switch  and  can  replace 
any  of  the  remaining  eight  SIO  boards.  The  output  of  the  A/B  switch  is  cabled  directly  to  jacks  on 
the  RCJB.  The  test  of  the  automatic  switch  of  the  spare  SIO  board  for  a  faulted  SIO  is  described 
in  the  Degraded  Operations  section  to  follow. 

Conclusions 

a.  Sufficient  flexibility  exists  to  assign  one  to  four  serial  ports  to  each  FAA  or  USAF  user. 

b.  The  serial  ports  transmit  data  with  correct  timing  and  pulse  characteristics  to  the  modems. 

c.  The  spare  SIO  board  can  be  manually  switched  on-line  to  replace  a  failed  SIO. 

4. 1.1. 2  Data  Formats. 


Purpose 

Ensure  that  the  ARSR-4  reliably  transmits  all  expected  message  types  to  the  ARTCC  with  the 
correct  bit  formatting. 

Test  Objectives 

a.  Verify  that  the  ARSR-4  outputs  messages  in  the  correct  Common  Digitizer  2  (CD-2) 
format  to  the  ARTCC. 

b.  Verify  that  the  ARSR-4  consistently  reports  beacon  and  search  Real-Time  Quality  Control 
(RTQCs)  and  status  messages  to  the  user  on  each  scan. 

c.  Verify  that  the  ARSR-4  can  detect,  process,  and  report  civil  and  military  beacon 
emergencies  in  the  proper  format. 

d.  Verify  that  changes  in  ARSR-4  status  are  detected  and  accurately  reported  in  the  status 
messages  sent  to  the  ARTCC. 

e.  Verify  that  the  status  reported  in  the  CD-2  status  message  is  consistent  with  beacon 
environmental  RMS  status. 

Test  Description 

An  Integrated  Radar  Evaluation  System  (IRES)  recorder  collected  data  on  the  ARSR-4  user  1 
(AFl  and  AF2)  ports.  The  formatter  was  configured  to  output  ARTCC  CD-2  messages.  Data 
sources  included  targets  of  opportunity,  beacon  test  targets,  or  data  collected  while  the  ARSR-4 
status  was  modified. 
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Target  of  opportunity  data  was  recorded  to  verify  that  the  ARSR-4  outputs  each  message  type  in 
the  correct  format.  The  data  was  also  analyzed  to  ensure  that  beacon  RTQCs,  search  RTQCs  and 
status  messages  were  output  to  the  user  on  each  scan. 

Beacon  replies  were  injected  at  Radio  Frequency  (RF)  into  the  ATCBI-5  to  verify  that  beacon  bits 
in  the  ARSR-4  CD-2  message  operated  as  expected  and  that  the  ARSR-4  properly  processed 
beacon  emergency  replies. 

The  test  configuration  is  shown  in  figure  4. 1.1. 2-1.  A  Sensis  Video  Beacon  Interrogator  Test  Set 
(VideoBITS)  modulated  the  RF  generator  of  a  lJPM-155  beacon  test  set.  The  replies,  at  RF,  were 
then  injected  into  the  ATCBI-5.  CD  data  was  recorded  at  the  ARSR-4  output  using  IRES. 


FIGURE  4. 1 . 1 .2- 1 .  BEACON  TEST  TARGET  CONFIGURATION 


The  beacon  test  target  scenarios  used  for  this  test  are  shown  in  table  4. 1 . 1 .2-1 .  DETECT06.SET 
and  DETECT08.SET  each  contained  12  test  targets.  The  test  targets  were  injected  at  various 
ranges  and  azimuths.  Mode  3/A  and  Mode  2  codes  were  chosen  to  exercise  all  bits  in  those  fields 
in  the  CD-2  message.  Target  altitude  was  varied  from  0  to  1 10,000  feet  to  test  the  Mode  C  field 
in  the  message. 

For  each  scenario,  the  round  reliability  was  set  to  76  percent,  where  round  reliability  is  a  measure 
of  the  aircraft’s  probability  of  responding  to  a  particular  interrogation.  This  probability  is  less  than 
unity  due  to  aircraft  maneuvers,  transponder  dead  time  because  of  another  interrogation,  and 
transponder  lockout  because  of  an  excessive  number  of  interrogations. 
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TABLE  4. 1 . 1 .2-1 .  BEACON  TEST  TARGET  SCENARIOS 


S(^ftan6x 


Description 


DETECT06.SET 


DETECT08.SET 


MCOOOO.SET 
INVAL  MC.SET 


12  individual  targets  witli  range  movement.  All  nmlengtlis  =  31  ACPs.  Replies  to  Modes 
3/A  2,  C  interrogations.  No  azimutli  movement.  Round  Reliability  =  76%. 


Target 

Start 

Start 

Range 

M3 

M2 

MC 

Range 

Azim. 

Movement 

Code 

Code 

Code 

(nin) 

(deg) 

(nm/lir) 

1 

30 

5 

600 

7776 

0001 

5230 

2 

50 

30 

550 

7775 

0002 

2546 

3 

70 

60 

500 

7773 

0004 

5230 

4 

90 

90 

450 

7767 

0010 

2546 

5 

no 

120 

400 

7757 

0020 

5230 

6 

130 

150 

350 

7737 

0040 

2546 

7 

150 

180 

300 

7677 

0100 

5230 

8 

170 

210 

250 

7577 

0200 

2546 

9 

190 

240 

200 

7377 

0400 

5230 

10 

210 

270 

150 

6777 

1000 

2546 

11 

230 

300 

100 

5777 

2000 

5230 

12 

240 

330 

50 

3777 

4000 

2546 

Same  as  DETECT06.SET,  except  all  heights  and  height  rates  as  listed: 


Target 


Start  Altitude 


1 

Ok 

2 

10k 

3 

20k 

4 

30k 

5 

40k 

6 

50k 

7 

60k 

8 

70k 

9 

80k 

10 

90k 

11 

100k 

12 

110k 

Altitude  Rate 
17  ft/sec 


Sixteen  spokes  witlr  ten  targets  per  spoke.  All  Mode  C  codes  =  0000. 

Sixteen  spokes  witli  ten  targets  per  spoke.  Mode  C  codes  are  invalid.  (i.e.  ABCD  =  0001, 
0051  or  0071). _ 


The  MCOOOO.SET  and  INVAL_MC.SET  scenarios  were  injected  to  test  the  ARSR-4  detection 
and  reporting  of  Mode  C  replies  containing  only  brackets  and  Mode  C  reported  altitudes  that  are 
outside  the  allowable  range  of  values. 

In  addition,  civil  and  military  emergency  replies  were  injected  into  the  ATCBI-5.  Four  scenarios 
tested  ARSR-4  beacon  emergency  processing  and  reporting.  The  four  scenarios  and  a  description 
of  each  are  listed  in  table  4.1.1 .2-2. 
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EMEROOl.SET  was  designed  to  test  the  ability  of  the  ARSR-4  to  process  civilian  emergency 
replies  (7500,  7600  or  7700  Mode  3/A  codes).  The  remaining  three  scenarios  (EMER002.SET  - 
EMER004.SET)  were  designed  to  test  military  emergency  processing.  A  military  transponder 
sends  four  replies  in  succession  to  denote  an  emergency.  The  FI  bracket  pulse  of  each  of  the  three 
trailing  replies  is  positioned  in  the  Special  Position  Identification  (SPI)  position  of  the  preceding 
reply. 


TABLE  4.1.1 .2-2  BEACON  EMERGENCY  PROCESSING  SCENARIOS 


Scenario 

Dek:ription 

EMEROOl.SET 

EMER002.SET 

EMER003.SET 

EMER004.SET 

4  of  each  (7500,  7600,  7700)  emergency  target.  Start  range  =  100  mn.  Range  movement 
varies  from  700  to  150  mn/hr.  Runlengtlis  vaiy  from  40  to  25. 

3  militaiy^  emergency  targets.  First  target  set  contains  4  replies  witl\  only  brackets  in  replies 
2-4.  Second  target  set  has  2nd  reply  missing.  Third  target  set  has  3rd  reply  missing. 

3  military  emergency  targets  witli  nominal  min  and  max  spacing  (up  to  300  ns  error).  Each 
target  set  contains  4  replies. 

1  3  military  emergency  targets.  Same  as  EMER002.SET  except  same  code  in  all  four  replies 
for  each  target  set. 

To  exercise  ARTCC  status  message  bits,  faults  were  injected  or  configuration  changes  were  made 
to  the  ARSR-4  while  data  were  recorded  with  IRES.  RMS  menus  were  observed  for  the 
appearance  of  alarms  with  injected  faults.  Recorded  data  were  analyzed  to  ensure  that  an  extra 
status  message  was  reported  at  the  time  of  the  change  and  that  the  correct  bit  was  set  in  the 
message.  A  description  of  the  action  taken  to  exercise  each  bit  is  included  in  the  Results  section  to 
follow. 

The  comparison  between  the  CD-2  reported  status  and  the  beacon  environmental  RMS  status 
could  not  be  performed  because  beacon  environmental  RMS  software  was  not  operating  at  the 
time  of  the  test. 

Data  Analysis 

The  IRES  RECORD  program  automatically  detects  reports  that  are  not  CD-2  compatible  and 
reports  an  error  on  the  reception  of  these  reports.  These  RECORD  indications  were  monitored 
during  recordings. 

IRES  SCANSUM  and  COUNTPCS  programs  were  used  to  verify  that  the  ARSR-4  reported  a 
search  RTQC,  beacon  RTQC,  and  at  least  one  status  message  per  scan  during  target  of 
opportunity  recordings. 

The  SHOWPCS  program  was  used  to  verify  that  injected  beacon  replies  produced  ARSR-4  CD-2 
messages  with  the  correct  range,  azimuth,  codes,  and  emergency  bits  set. 

SHOWPCS  and  SHOWSTAT  programs  were  used  to  inspect  the  recorded  status  messages  to 
ensure  that  the  expected  bits  toggled  when  the  ARSR-4  configuration  was  changed  or  when  a 
fault  was  injected  into  the  system. 
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Results 


The  ARSR-4  transmits  messages  that  are  compatible  with  the  CD-2  format.  The  ARSR-4  output  all 
message  types  to  the  ARTCC  user  with  the  exception  of  a  search  permanent  echo  (PE).  The  clutter 
returns  from  the  selected  PE  are  filtered  by  ARSR-4  doppler  processing  and  are  not  consistently 
reported  to  the  user.  Discussion  with  Los  Angeles  ARTCC  personnel  indicated  that  the  beacon  PE  is 
primarily  monitored  and  the  absence  of  a  search  PE  is  not  an  operational  problem. 

Inspection  of 26512  scans  of  target  of  opportunity  data  recorded  during  the  OT&E  retest  period  (from 
June  5, 1995  to  July  20, 1995)  showed  only  two  cases  where  a  beacon  RTQC  was  not  output  on  a 
scan  and  three  cases  where  a  search  RTQC  was  not  output  on  a  scan.  At  least  one  status  message  was 
reported  on  each  scan. 

The  search  RTQC  dropouts  may  have  been  caused  by  external  interference  whose  effects  may  have 
been  exaggerated  by  the  close  proximity  of  the  ARSR-3.  The  causes  for  the  beacon  RTQC  dropouts 
are  unknown.  The  low  RTQC  dropout  rate  is  not  an  operational  problem. 

Inspection  of  IRES  data  recorded  when  DETECT06.SET  and  DETECT08.SET  scenarios  were 
injected,  showed  that  detected  targets  reported  the  expected  range,  azimuth,  and  Mode  3/A, 

Mode  2,  and  Mode  C  codes.  Each  of  the  Mode  code  bit  combinations  were  successfully  verified 
during  OT&E  retest. 

Results  showed  that  when  targets  with  0000  Mode  C  codes  (brackets  only)  were  injected,  the 
ARSR-4  correctly  reported  -1000  feet  altitude.  When  targets  with  invalid  Mode  C  altitudes  (D1 
bit  set  and  Cl,  C2,  and  C4  bits  =  000,  101,  or  1 1 1)  were  injected,  the  ARSR-4  correctly  reported 
-99900-foot  altitude  in  the  beacon  message  during  OT&E  retest. 

During  the  initial  phase  of  OT&E,  the  ARSR-4  failed  to  detect  a  military  emergency  situation  and 
report  a  7700  code  in  position  of  the  first  reply.  Instead,  four  reports  were  generated  for  the 
injected  reply  trains.  The  first  three  replies  in  each  train  had  the  SPI  bit  set  in  the  report  sent  to  the 
user.  This  problem  was  described  in  TDR  ACW-098  listed  in  appendix  A. 

After  changes  were  made  to  ARSR-4  software  to  correct  the  military  emergency  detection 
problems,  the  tests  were  repeated  during  OT&E  regression.  For  each  beacon  emergency  scenario 
injected,  the  ARSR-4  correctly  reported  a  7700  code  with  the  emergency  bit  set  in  the  beacon 
message. 

A  second  beacon  emergency  problem  was  discovered  during  OT&E.  When  a  7700  coded  Mode  2 
reply  was  input  to  the  ARSR-4  processor,  the  LDC  erroneously  reported  the  reply  as  an 
emergency.  For  this  case,  the  false  emergency  indication  was  limited  to  the  LDC  and  was  not  sent 
to  the  ARTCC.  This  problem  is  described  in  TDR  ACW-1 13,  listed  in  appendix  A. 

No  ARSR-4  change  was  made  to  correct  the  erroneous  reporting  of  a  7700  Mode  2  code  as  an 
emergency  target  on  the  LDC  and  therefore  no  further  testing  was  performed  during  OT&E 
regression.  Since  this  problem  is  localized  to  the  LDC,  the  controller  does  not  see  the  false  beacon 
emergency  target. 
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Table  4.1.1 .2-3  shows  the  results  of  status  bit  tests.  Of  the  34  bits  in  the  ARTCC  status  message,  27 
bits  were  demonstrated  to  operate  properly.  Seven  bits  were  not  tested.  Four  of  those  bits  (BCOL, 
OLBA,  SBBEAL,  OLRBAL)  needed  an  operational  Integral  Systems  Monitor  (ISM)  to  test.  The 
beacon  environmental  RMS,  which  interfaces  to  the  ATCBI  ISM,  was  not  functioning  at  the  time  of 
the  test.  The  remaining  three  bits  (M4ALA,  BTPRAA,  and  BTPAZA)  were  not  tested  due  to  the 
inability  to  inject  a  proper  fault  at  Mt.  Laguna. 

Conclusions 

a.  The  ARSR-4  reports  all  expected  message  types  in  the  correct  format  to  the  ARTCC 
except  a  search  permanent  echo.  Users  at  the  Los  Angeles  ARTCC  do  not  consider  the  absence 
of  a  search  PE  as  an  operational  problem. 

b.  The  ARSR-4  reliably  output  beacon  and  search  RTQCs  and  status  messages  to  the  user 
during  the  OT&E  retest  period. 

c.  All  of  the  fields  in  the  ARTCC  beacon  message  operate  as  expected,  including  the  beacon 
emergency  indications. 

d.  Mode  2  replies  with  a  7700  code  are  erroneously  shown  as  an  emergency  on  the  LDC  Plan 
Position  Indicator  (PPI)/Random  Access  Plan  Position  Indicator  (RAPPI).  The  beacon  messages 
sent  to  the  ARTCC  are  not  effected. 

e.  Changes  in  ARSR-4  status  are  detected  and  accurately  reported  in  the  status  messages  sent 
to  the  ARTCC.  The  27  status  bits  that  were  exercised  (out  of  a  possible  34  bits),  operated 
properly. 

f  Since  the  beacon  environmental  RMS  was  not  functioning  during  the  retest  period,  four  of 
the  status  bits  were  not  tested  and  a  comparison  between  the  ARSR-4  status  and  beacon 
environmental  RMS  status  was  not  done. 

Recommendations 

a.  When  the  beacon  environmental  RMS  becomes  operational,  the  status  reported  by  the 
ARSR-4  and  beacon  environmental  RMS  should  be  compared  for  consistency. 

b.  The  erroneous  emergency  indication  on  the  LDC  when  7700  coded  Mode  2  replies  are 
processed  should  be  fully  documented  in  the  Technical  Instruction  Books. 


14 


TABLE  4. 1 . 1 .2-3 .  ARTCC  STATUS  BIT  TEST  RESULTS 


Bit# 

Bit 

Description: 

Test  Method 

Results 

1 

TEST 

Test  Target 

Checked  test  bits  in  data 

Pass 

11 

FAA 

FAA  User 

Configured  User  1  as  FAA 

Pass 

12 

AF 

Air  Force  User 

Configured  User  1  as  AF 

Pass 

14 

RDRCHN 

Radar  Channel 

Always  set  to  1 

Pass 

15 

BCOL 

BCN  Chan.  Online 

Needs  Operational  ISM 

Not  Tested 

16 

DPALA 

Data  Proc.  Alann 

Removed  Modem  cable  in  RCJB 

Pass 

17 

OLBA 

Online  BCN  Alann 

Needs  Operational  ISM 

Not  Tested 

18 

HNBO 

1/2  nm  offset 

Enabled,  then  disabled  1/2  nm  beacon 
offset 

Pass 

19 

M4ALA 

Mode  4  Alarm 

Not  Tested 

20 

POLCHA 

Polarization  Change 

Set  sectors  0-3  to  CP.  Reset  those  sectors 
to  LP.  Set  all  sectors  to  CP.  Reset  to  LP. 

Pass 

21 

SBBEAL 

Standby  BCN  Alann 

Needs  Operational  ISM 

Not  Tested 

22 

OLRBAL 

Online  RBPM  Alarm 

Needs  Operational  ISM 

Not  Tested 

25 

SYSOH 

System  Overheat 

Adjusted  IF  cabinet  temp  thresholds  to 
cause  soft,  then  hard  alarms 

Pass 

29 

BRTQCA 

Beacon  RTQC  alarm 

Removed  cable  at  J52  in  RCJB 

Pass 

30 

SRTQCA 

Search  RTQC  Alarm 

Toggled  Search  RTQC  at  menu  5.2.8 

Pass 

31 

BTPRAA 

BCN  clock  failure 

Needs  Hardware  Fault  Injection 

Not  Tested 

32-35 

OUSRAL* 

Output  Service  Alarms 

Run  457,468 

Pass 

36 

BTPAZA 

BCN  Azimuth  Alarm 

Needs  Hardware  Fault  Injection 

Not  Tested 

37-38 

BETAPR 

BCN  Proc.  Status 

Placed  Beacon  B  to  REPR  to  verify 
‘‘Redundancy  In  Use”.  Faulted  Beacon  A 
by  removing  mode  pair  triggers. 

Pass 

40-41 

WXCHST 

Weather  Channel  Status 

Ground  TP22  on  AlOl  with  spare  in 
REPR. 

Pass 

42 

WXSTAL 

Weather  Station  Alarm 

Removed  J2  cable  at  top  of  Data 

Processor  cabinet 

Pass 

43 

MODALA 

Modem  Alarm 

Removed  Modem  cable  in  RCJB 

Pass 

44 

TISALA 

Time  In  Storage  Alarm 

Set  Time  in  Storage  to  minimum  at 
menu  5.62.1.  Injected  capacity  test 
targets. 

Pass 

45 

BOA 

Buffer  Overload 

Same  as  TISALA 

Pass 

46 

BOFA 

Buffer  Overflow 

Same  as  TISALA 

Pass 

48-51 

P0*STA 

Port  1-4  Status 

Varied  User  1  port  assignments 

Pass 
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4. 1  ■  1 .3  Degraded  Operations. 


Purpose 

Ensure  that,  in  the  event  of  a  failed  modem,  the  ARSR-4  transmits  data  over  the  remaining 
operating  modems  and  that  high  priority  messages  are  given  preference  in  transmission. 

Test  Objectives 

a.  Verify  that  the  ARSR-4  can  detect  a  modem  failure  and  redirect  data  transmission  over 
the  remaining,  operating  modem  channels. 

b.  Verify  that  priority  messages  (i.e.,  beacon  emergency,  status,  RTQC)  reports  are  output 
during  overflow  and  overload  conditions. 

Test  Description 

Data  was  recorded  using  IRES  setup  on  user  1  ports  (AFl  and  AF2).  The  ports  were  configured 
for  ARTCC  operation  and  each  operated  at  4800  baud.  Emergency  beacon  test  targets  (codes 
7700,  7600,  and  7500)  were  injected  at  RF  into  the  ATCBI-5.  Twelve  targets  (four  of  each 
emergency  code)  were  injected  per  scan.  The  25MAY95  software  build  was  installed  in  the 
ARSR-4  for  the  test. 

Two  tests  (RUN  527  and  RUN  528)  were  performed  to  verify  that  the  ARSR-4  can  detect  an 
unterminated  serial  port  and  route  the  data  to  an  operational  channel.  RUN  527  contained  65 
scans  of  data.  On  scan  25  of  the  recording,  the  AFl  cable  was  disconnected  from  the  J28  jack  in 
the  RCJB,  leaving  only  the  AF2  cable  connected  for  user  1.  The  AFl  cable  was  not  reconnected 
to  J28  during  the  remainder  of  the  recording. 

On  scan  45,  the  Time  In  Storage  (TIS)  parameter  on  RMS  menu  5. 6. 2. 7  was  adjusted  to  .5 
seconds  in  an  attempt  to  induce  TIS  alarms  in  the  formatter.  By  design,  the  ARSR-4  should  not 
output  data  that  exceeds  this  TIS  limit.  The  data  was  inspected  to  verify  that  priority  reports 
were  not  eliminated  due  to  the  TIS  filtering. 

RUN  528  contained  90  scans  of  data.  The  TIS  was  reduced  to  .25  seconds  prior  to  the  start  of 
recording.  The  cable  at  J28  (AFl)  was  disconnected  at  scan  25  of  the  recording.  The  cable  was 
reconnected  to  J28  on  scan  60. 

Data  Analysis 

During  each  test,  the  ARSR-4  RMS  alarm  menus  were  monitored  to  ensure  that  the  TIS  and 
modem  faults  were  detected  and  reported  by  Built-In  Test  (BIT).  Alarm  data  were  also  recorded 
on  a  computer  connected  to  the  ARSR-4  MPS  port.  The  Maintenance  Processor  System  (MPS) 
text  files  were  also  analyzed  to  ensure  that  the  ARSR-4  reported  the  expected  modem  and  TIS 
alarms. 

The  surveillance  data  was  analyzed  using  IRES.  PLOTSCAN  plotted  the  report  counts  per  scan 
and  produced  tables  containing  the  data  counts.  The  FILTER  program  removed  search  and  non¬ 
emergency  beacon  reports  from  the  file.  The  COUNTPCS  program  counted  the  number  of 
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beacon  emergency  reports,  beacon  RTQC,  and  status  messages  recorded.  SHOWPCS  was  used 
to  ensure  that  the  modem  and  TIS  alarms  were  accurately  reported  in  the  ARTCC  status  message. 

Results 

Figure  4. 1 . 1 .3-1  is  a  PLOTSCAN  plot  for  RUN  527.  There  are  two  graphs  in  the  figure.  Each 
graph  plots  report  counts  versus  scans.  The  upper  graph  displays  the  radar  only  (RO)  (upper, 
jagged  trace),  radar  beacon  merge  (RB)  (middle  trace),  and  beacon  only  (BO)  (lower  trace) 
counts  per  scan.  The  lower  graph  displays  search  RTQC,  beacon  RTQC,  status  message,  and 
strobe  counts  per  scan. 

The  upper  graph  of  figure  4. 1 . 1 .3- 1  shows  that  the  beacon  report  counts  per  scan  remain  fairly 
constant  throughout  the  data  recording.  The  radar  only  trace  is  likely  fluctuating  due  to  external 
interference  and  interference  fi’om  the  collocated  ARSR-3. 

In  the  lower  graph  of  figure  4. 1 . 1 .3-1,  the  two  largest  spikes  in  the  data  counts  are  due  to  extra 
status  messages  on  the  scan  when  the  cable  was  disconnected  and  on  the  scan  when  the  RMS  TIS 
parameter  was  changed.  Note  that  there  was  no  significant  loss  of  data  when  the  cable  was 
disconnected  in  scan  25.  This  indicates  that  the  ARSR-4  detected  the  unterminated  port  and 
routed  data  over  the  operating  port. 

Review  of  the  ARTCC  status  message  and  MPS  data  showed  that  the  faulted  port  was  in  alarm 
while  the  cable  was  disconnected.  However,  a  TIS  alarm  condition  was  reported  for  only  several 
scans  of  the  recording,  indicating  that  the  RMS  TIS  parameter  was  not  low  enough  for  the  test. 

The  RUN  527  data  was  filtered  to  remove  RO  and  nonemergency  beacon  targets.  Figure  4. 1.1-3- 
2  shows  the  PLOTSCAN  display  of  beacon  emergency  data  counts  in  the  upper  graph  and  status, 
and  beacon  and  search  RTQC  counts  in  the  lower  graph.  Table  4. 1.1. 3-1  presents  the  data  in 
tabular  form. 

In  the  upper  graph  of  figure  4.1.1 .3-2,  the  BO  emergency  reports  are  shown  in  the  upper  trace 
and  the  merged  emergency  reports  are  shown  as  small,  individual  spikes  in  the  lower  trace. 

Inspection  of  the  data  using  the  SHOWPCS  program  revealed  that  the  ARSR-4  did  not  output  1 
of  the  12  injected  beacon  emergency  reports  on  scans  1 1,  45,  and  46.  On  scans  1 1  and  46,  the 
emergency  test  target  was  reported  Avith  a  zero  Mode  3/A  code  due  to  garbling  from  a  nearby  real 
aircraft.  The  emergency  report  was  missing  on  scan  45  due  to  the  disconnection  of  the  modem 
cable. 

The  lower  graph  of  figure  4.1.1 .3-2  shows  that  extra  status  messages  were  output  to  the  ARTCC 
on  the  scans  where  the  AFl  cable  was  disconnected  and  where  the  TIS  parameter  was  adjusted. 
Note  the  RTQCs  were  reported  for  each  scan  except  the  scan  when  the  cable  was  disconnected. 
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Reponte  Repor-ts 


TABLE  4. 1 . 1 .3-1 .  RUN527  -  EMERGENCY  BEACON  REPORTS 


Scan 

BO 

RB 

Srch 

RTQC 

Ben 

RTQC 

Stat. 

Scan 

BO 

RB 

Srcli 

RTQC 

Stat. 

1 

12 

0 

1 

1 

1 

34 

12 

0 

1 

1 

1 

2 

12 

0 

1 

1 

1 

35 

12 

0 

1 

1 

1 

3 

12 

0 

1 

1 

1 

36 

12 

0 

1 

1 

1 

4 

12 

0 

1 

1 

1 

37 

12 

0 

1 

1 

1 

5 

12 

0 

1 

1 

1 

38 

12 

0 

1 

1 

1 

6 

12 

0 

1 

1 

1 

39 

12 

0 

1 

1 

1 

7 

12 

0 

1 

1 

1 

40 

12 

0 

1 

1 

1 

8 

12 

0 

1 

1 

1 

41 

12 

0 

1 

1 

1 

9 

12 

0 

1 

1 

1 

42 

12 

0 

1 

1 

1 

■  10 

12 

0 

1 

1 

1 

43 

12 

0 

1 

1 

1 

11 

11 

0 

1 

1 

1 

44 

12 

0 

1 

1 

1 

12 

12 

0 

1 

1 

1 

45 

11 

0 

1 

0 

9 

13 

12 

0 

1 

1 

1 

46 

11 

0 

1 

1 

1 

14 

12 

0 

1 

1 

1 

47 

11 

1 

1 

1 

1 

15 

12 

0 

1 

1 

1 

48 

12 

0 

1 

1 

1 

16 

12 

0 

1 

1 

1 

49 

12 

0 

1 

1 

1 

17 

12 

0 

1 

1 

1 

50 

12 

0 

1 

1 

1 

18 

12 

0 

1 

1 

1 

51 

12 

0 

1 

1 

1 

19 

12 

0 

1 

1 

1 

52 

11 

1 

1 

1 

1 

20 

12 

0 

1 

1 

1 

53 

12 

0 

1 

1 

1 

21 

12 

0 

1 

1 

1 

54 

12 

0 

1 

1 

1 

22 

12 

0 

1 

1 

1 

55 

12 

'  0 

1 

1 

1 

23 

12 

0 

1 

1 

1 

56 

:  12 

0 

1 

1 

1 

24 

12 

0 

1 

1 

1 

57 

12 

0 

1 

1 

2 

25 

12 

0 

1 

1 

5 

58 

12 

0 

1 

1 

1 

26 

12 

0 

1 

1 

1 

59 

12 

0 

1 

1 

2 

27 

12 

0 

1 

1 

1 

60 

12 

0 

1 

1 

1 

28 

12 

0 

1 

1 

1 

61 

12 

0 

1 

1 

1 

29 

12 

0 

1 

1 

1 

62 

12 

0 

1 

1 

1 

30 

12 

0 

1 

1 

1 

63 

12 

0 

1 

1 

1 

31 

12 

0 

1 

1 

1 

64 

12 

0 

1 

1 

1 

32 

12 

0 

1 

1 

1 

65 

12 

0 

1 

1 

1 

33 

12 

0 

1 

1 

1 

Figure  4.1.1 .3-3  contains  a  PLOTSCAN  plot  for  RUN  528.  The  figure  has  a  similar  appearance 
to  figure  4. 1.1. 3-1  except  that  there  were  more  status  messages  reported  as  the  system 
transitioned  in  and  out  of  TIS  alarm.  As  was  the  case  for  RUN527,  the  reinforced  and  beacon 
reports  per  scan  remain  fairly  constant.  Review  of  the  status  message  and  MPS  data  showed  that 
the  modem  alarm  (MOD ALA  and  POISTA)  were  reported  at  the  expected  times. 

Figure  4. 1.1. 3-4  shows  the  PLOTSCAN  display  of  beacon  emergency  data  counts  in  the  upper 
graph  and  status,  and  beacon  and  search  RTQC  counts  in  the  lower  graph.  Table  4.1.1 .3-2 
presents  the  data  in  tabular  form. 
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On  scans  9,  21,  and  22,  one  of  the  twelve  injected  emergency  targets  was  not  reported  to  the 
user.  In  each  of  those  cases,  the  emergency  test  target  was  reported  with  a  zero  Mode  3/A  code 
due  to  garbling  from  a  nearby  real  aircraft. 

The  lower  graph  in  figure  4.1. 1.3-4  shows  that  extra  status  messages  were  output  to  the  ARTCC 
on  the  scans  where  the  AFl  cable  was  disconnected  (scan  25)  and  reconnected  (scan  60).  Search 
and  beacon  RTQCs  were  reported  on  each  scan. 

Inspection  of  the  status  message  contents  using  SHOWPCS  revealed  that  TIS  alarms  were 
reported  for  most  of  the  time  between  scan  28  and  scan  6 1  of  the  recording.  In  that  time,  the 
ARSR-4  reported  all  expected  beacon  emergency  targets,  RTQCs,  and  at  least  one  status  message 
per  scan. 

Conclusions 

a.  The  ARSR-4  successfully  detects  a  failed  modem  port  and  routes  data  over  the  remaining 
operational  channels. 

b.  Priority  messages  (beacon  emergency,  RTQCs,  and  status)  are  not  eliminated  during  buffer 
overload  and  buffer  overflow  conditions. 

4. 1 . 1 .4  Modem/Modem  Interface. 


Purpose 

Ensure  that  the  local  modems  communicate  properly  with  the  remote  modems. 

Test  Objective 

Verify  that  the  modems  provide  for  the  transmission  of  ARSR-4  digital  messages  to  the  end  user 
with  a  low  transmission  error  rate. 

Test  Description 

The  modem  interface  between  the  ARSR-4  at  Mt.  Laguna  and  the  Los  Angeles  ARTCC  was 
tested  to  ensure  that  the  modems  were  properly  strapped  and  that  data  transmission  across  the 
modem  lines  was  satisfactory. 

Codex  3600  modems  were  used  to  transmit  ARSR-4  data  to  the  Center.  The  configuration  and 
strapping  of  both  modems  were  optimized  to  obtain  the  best  data  throughput  and  quick  diagnostic 
responses. 

Codex  modem  straps  are  contained  in  table  4. 1 . 1 .4-1 .  Straps  which  are  not  listed  remained  at  the 
manufacturer’s  default  settings.  The  ARTCC  Codex  modem  was  configured  as  the  Remote,  while 
the  Mt.  Laguna  modem  was  configured  as  Local.  Modem  strapping  information  was  obtained 
from  the  Codex  3600  Series  Users  Manual,  Part  #09299  Rev  B. 
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Reponts  Reponts 


FIGURE  4.1. 1.3-3  RUN  528  -  REPORT  COUNTS  PER  SCAN 


FIGURE  4.1. 1.3-4  RUN  528  -  EMERGENCY  BEACON  REPORTS 
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TABLE  4. 1 . 1 .3-2.  RUN528  -  EMERGENCY  BEACON  REPORTS 


TABLE  4. 1 . 1 .4-1 .  CODEX  3600  MODEM  PARAMETERS 


Description 

Value  -  Local  (Remote) 

Current  TX  Data  Rate 

19.2  K  (19.2  K) 

Current  Rx  Data  Rate 

19.2  K  (19.2  K) 

Port  1  Rate 

2.4  K  (2.4  K) 

Port  2  Rate 

2.4  K  (2.4  K) 

Port  3  Rate 

2.4  K  (2.4  K) 

Port  4  Rate 

2.4  K  (2.4  K) 

Port  5  Rate 

2.4  K  (2.4  K) 

Port  6  Rate 

2.4  K  (2.4  K) 

Port  7  Rate 

2.4  K  (2.4  K) 

Port  8  Rate 

2.4  K  (2.4  K) 

OP  MODE 

Turbo  PP 

Rate-0 

19.2  KBPS  (19.2  KBPS) 

TX-LVL 

-13  dBm  (-13  dBm) 

CDTHR 

-26/-31  (-26/-31) 

Internal  modem  diagnostics  tests  were  performed  to  verify  modem  operation,  line  quality,  and 
data  integrity.  During  BIT  Error  Rate  and  Block  Error  Rate  (BER)  tests,  the  transmit  and  receive 
modems  looped  data  through  the  other  modem  to  the  originating  modem  where  the  data  was 
compared.  The  error  rates  were  then  displayed  on  the  modem  front  panel.  The  accumulated  error 
rates  were  recorded  for  the  1 5-minute  test. 

In  addition  to  the  internal  modem  diagnostics,  data  was  recorded  at  the  output  of  the  ARSR-4 
(using  an  IRES  recorder)  and  at  the  output  of  the  ARTCC  modem  (using  an  MX6  recorder).  The 
two  users  were  identically  configured  with  each  containing  three  ports  of  2400  baud.  The  data 
was  then  compared. 


Data  Analysis 

The  MX6  recorded  data  was  converted  to  IRES  format  using  the  COPYCD  program.  The  two 
data  sets  were  then  compared  using  the  IRES  COMPARE  program.  In  addition,  the  COUNTPCS 
program  verified  that  the  ARSR-4  output  the  expected  Search  RTQC,  Beacon  RTQC,  and  Status 
message  counts  on  each  scan. 

Results 

At  the  start  of  Codex  tests,  the  modem  power  was  cycled  which  initiated  the  internal  modem  self 
test.  The  internal  self  test  automatically  verified  proper  modem  operation  by  displaying  the 
transmit  data  rate  on  the  front  panel. 


Table  4.1.1 .4-2  shows  the  Codex  modem  performance  parameters  as  measured  by  the  Circuit 
Quality  Monitoring  System  (CQMS)  of  the  modem.  All  values  are  within  tolerance. 
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TABLE  4.1.1 .4-2.  CODEX  MODEM  LINE  CHARACTERISTICS 


Description 

VaiiigLxx:al,(ROTote 

Phase  Jitter  (PJ) 

0  Deg.,  (0  Deg.) 

Received  Level  (RL) 

-13  dB,  (-15  dB) 

Error  Rate  Percent  (ERP) 

0  %,  (0  %) 

Phase  Hits  (PH) 

0  Hits.  (0  Hits) 

Drop  Outs  (DO) 

0,(0) 

SNR 

033,  (036) 

RTN 

1,(2) 

BP 

0,(0) 

The  BER  test  was  performed  for  a  15-minute  period  with  a  normal  configuration  of  three  ports 
operating  at  2400  baud.  Zero  block  errors  and  zero  bit  errors  were  detected  on  ports  1,  2,  and  3. 
A  second  5-minute  BER  test  was  conducted  with  a  single  channel/port  configured  at  9600  baud. 
Zero  errors  were  reported  on  the  single  port. 

Data  counts  for  the  Mt.  Laguna  and  Los  Angeles  recorded  data  are  shown  in  table  4.1.1 .4-3.  The 
results  show  identical  target  counts  for  each  scan  except  scan  43.  In  scan  43,  the  Mt.  Laguna  data 
(denoted  by  and  asterisk  in  the  table)  contained  one  more  search  report  than  the  Palmdale  data. 

The  single  search  report  was  most  likely  lost  due  to  an  error  in  transmission.  Of  the  14229  reports 
output  from  the  ARSR-4  during  the  test,  the  single  dropped  report  corresponds  to  an  error  rate  of 
approximately  7  x  10■^  This  low  error  rate  is  operationally  acceptable. 

Conclusions 

a.  The  modem  settings,  line  characteristics,  and  line  quality  are  acceptable. 

b.  The  error  rate  checks  and  other  diagnostic  tests  performed  internally  by  each  modem 
indicate  that  the  modems  can  adequately  configure,  monitor,  and  test  their  individual 
communication  lines. 

c.  The  Mt.  Laguna  ARSR-4  transmits  data  to  the  ARTCC  with  an  acceptably  low  error  rate. 

4. 1 .2  Surveillance  via  Mode  S  to  ARTCC. 

Purpose 

The  purpose  of  this  test  was  to  verify  that  the  ARSR-4,  when  interfaced  to  a  Mode  S,  provides 
the  proper  data  in  a  timely  manner  to  the  ARTCC. 

Test  Objectives 

a.  Verify  that  the  ARSR-4/Mode  S  Interface  Control  Document  (ICD)  provides  information 
consistent  with  an  effective  interface  with  the  Mode  S. 

b.  Verify  that  the  ARSR-4  transmits  correct  status  information  to  the  Mode  S. 
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TABLE  4. 1.1. 4-3.  DATA  COUNTS  FOR  MT.  LAGUNA  AND  LOS  ANGELES 


Scan 

Radar 

Only 

Beacon 

Only 

Radar 

Beacon 

Search 

RTQC 

Beacon 

RTQC 

Strobe 

Status 

Total 

123 

54 

151 

1 

1 

60 

390 

105 

58 

143 

1 

1 

13 

321 

102 

63 

145 

1 

1 

0 

1 

313 

114 

71 

140 

1 

1 

1 

328 

5 

106 

72 

143 

1 

1 

0 

1 

324 

6 

106 

76 

135 

1 

1 

1 

320 

7 

91 

79 

132 

1 

1 

1 

305 

8 

86 

74 

140 

1 

1 

1 

303 

9 

90 

84 

133 

1 

1 

0 

1 

310 

10 

86 

75 

138 

1 

1 

1 

302 

11 

106 

76 

136 

1 

1 

0 

1 

321 

12 

110 

71 

134 

1 

1 

1 

1 

319 

13 

122 

71 

140 

1 

1 

1 

1 

337 

14 

88 

76 

130 

1 

1 

0 

1 

297 

15 

94 

72 

135 

1 

1 

0 

1 

304 

16 

119 

77 

136 

1 

1 

1 

1 

336 

17 

107 

81 

128 

1 

1 

2 

1 

321 

18 

no 

82 

137 

1 

1 

2 

1 

334 

19 

106 

82 

129 

1 

1 

0 

1 

320 

20 

95 

81 

133 

1 

1 

0 

1 

312 

21 

109 

82 

133 

1 

1 

2 

1 

329 

22 

123 

74 

139 

1 

1 

2 

1 

341 

23 

115 

75 

143 

1 

1 

2 

1 

338 

24 

131 

75 

141 

1 

1 

2 

1 

352 

25 

101 

79 

143 

1 

1 

2 

1 

328 

26 

130 

76 

146 

1 

1 

2 

1 

357 

27 

93 

75 

148 

1 

1 

2 

1 

321 

28 

111 

67 

149 

1 

1 

2 

1 

332 

29 

124 

79 

142 

1 

1 

2 

1 

350 

30 

128 

75 

137 

1 

1 

2 

1 

345 

31 

106 

77 

136 

1 

1 

2 

1 

324 

32 

113 

69 

140 

1 

1 

0 

1 

325 

33 

109 

69 

140 

1 

1 

0 

1 

321 

34 

106 

71 

144 

1 

1 

2 

1 

326 

35 

114 

72 

143 

1 

1 

2 

1 

334 

36 

107 

68 

139 

1 

1 

2 

1 

319 

37 

106 

57 

144 

1 

1 

2 

1 

312 

38 

115 

66 

147 

1 

1 

2 

1 

333 

39 

125 

74 

146 

1 

1 

2 

1 

350 

40 

104 

62 

150 

1 

1 

0 

1 

319 

41 

102 

61 

125 

1 

1 

1 

4 

295 

42 

92 

56 

152 

1 

1 

0 

1 

303 

43 

105 

64 

139 

1 

1 

0 

4 

314 

*140 

*315 

44 

93 

70 

142 

1 

1 

0 

1 

308 

45 

108 

68 

146 

1 

1 

0 

1 
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Test  Description 

Due  to.  the  unavailability  of  the  Mode  S  for  testing  at  Mt.  Laguna,  the  Mode  S  OT&E  integration 
tests  were  limited  to  review  of  the  ARSR-4/Mode  S  interface  control  document  and  simulated 
tests  using  a  protocol  analyzer  to  emulate  the  Mode  S. 

For  the  simulated  tests,  a  Telenex  Turbo  8600  protocol  analyzer  was  configured  to  emulate  Data 
Communications  Equipment  (DCE).  The  Mode  S  RS-530  port  in  the  ARSR-4  was  configured  to 
communicate  at  9600  baud.  The  test  consisted  of  verifying  that  status  bits  accurately  reflected  the 
status  of  the  ARSR-4. 

Data  Analysis 

The  review  of  the  ARSR-4/Mode  S  interface  control  document  was  performed  by  the  Mode  S 
OT&E  group  at  the  FAA  William  J.  Hughes  Technical  Center  (ACT-3 10).  The  Mode  S  OT&E 
test  group  has  been  extensively  involved  in  Airport  Surveillance  Radar  Model  9  (ASR-9)/Mode  S 
interface  testing.  The  document  was  reviewed  for  the  technical  content  concerning  ARSR-4  and 
Mode  S  channel  switching  and  switching  to  Interm  Beacon  Interrogator  (IBI)  mode  in  the 
Mode  S. 

ARSR-4  data  collected  with  the  protocol  analyzer  was  converted  to  IRES  format,  then  inspected 
for  proper  message  content  using  IRES  SHOWPCS  and  SHOWSTAT  programs. 

Results 


Interface  Control  Document  Review 

Review  of  the  ARSR-4/Mode  S  ICD  produced  several  critical  concerns. 

In  section  3.2. 1.1. c  of  the  ICD,  the  statement  “Both  Mode  S  processors  reporting  DCE  Ready 
lines  ON  or  OFF  for  more  than  150  millisecond  (ms)  constitute  a  failure  of  both  Mode  S 
processors,  and  therefore,  causes  the  ARSR-4  to  go  to  backup  mode.”  would  present  a  problem  if 
implemented.  In-channel  recoveries  commonly  take  up  to  1  second  to  complete,  during  which 
time  DCE  READY  may  be  dropped.  Assuming  DCE  READY  is  dropped  for  longer  than  1 50  ms, 
the  ARSR-4  would  configure  into  backup  mode,  dropping  Data  Terminal  Equipment  (DTE) 
READY,  causing  the  Mode  S  to  first  switch  channels  and  then  drop  into  Air  Traffic  Control 
Beacon  Interrogator  (ATCBI)  mode.  This  would  be  a  gravely  undesirable  result  after  a  simple 
Mode  S  software  trap  had  caused  an  in-channel  recovery.  Suggest  designing  the  ARSR-4 
interface  to  allow  for  up  to  a  1 -second  loss  of  DCE  READY  to  avoid  unnecessary  reconfiguration 
of  the  two  systems.  This  is  the  current  implementation  in  the  ASR-9  software. 

In  section  3.2.6. 1.2.1,  Online  Status  Loop  Test,  the  ARSR-4  looping  a  status  message  “at  a 
minimum”  of  once  per  scan  sounds  insufficient.  The  ASR-9  currently  issues  a  “health  check” 
message  every  other  sector.  Moreover,  waiting  4  seconds  before  incrementing  the  failure  counter 
sounds  like  too  long  a  time  duration.  If  the  failure  counter  (defined  at  the  beginning  of  the 
section)  is  set  to  3,  for  instance,  then  data  can  be  lost  for  up  to  12  seconds  before  a  hard  fault  is 
declared. 
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Section  3.2.6. 1.3,  Mode  S  Active  Channel  Reconfiguration,  is  incomplete.  This  section  discusses 
how  the  ARSR-4  tracks  channels  of  the  Mode  S,  but  fails  to  discuss  how  the  ARSR-4  must  cause 
Mode  S  channel  switches  to  fully  utilize  all  interface  paths.  For  example,  if  a  hard  interface  fault 
occurs  (the  necessary  number  of  status  loopback  messages  are  consecutively  missing),  the  ARSR- 

4  first  switches  Serial  I/O  boards.  Should  the  status  messages  still  be  missing,  the  ARSR-4  must 
force  a  Mode  S  reconfiguration  (channel  switch)  by  dropping  the  uplink  discrete  on  the  on-line 
RS-530  channel.  The  Mode  S  will  switch  channels,  causing  DCE  READY  in  the  newly  on-line 
channel  to  go  high.  The  ARSR-4  must  sense  this,  switch  RS-530  channels  on  the  spare  (now  on¬ 
line)  Serial  I/O  board,  and  must  now  provide  the  uplink  discrete  (DTE  READY)  to  give  this 
Mode  S  channel  a  chance.  Should  the  loopback  status  messages  still  be  missing,  the  ARSR-4  can 
either  switch  back  to  the  original  Serial  I/O  board,  or  drop  the  uplink  discrete  again  to  force 
reconfiguration  into  backup  mode  at  the  Mode  S. 

Regarding  section  3.2.6. 1.6,  functionality  does  not  exist  in  the  fielded  full-up  Mode  S  system  to 
support  transition  into  and  out  of  Mode  4  operation. 

In  section  3. 3. 2. 2. 4,  it  is  unclear  at  this  time  how  much  of  the  required  analog  interface 
functionality  currently  exists  in  the  Mode  S  interrogator.  With  the  Mode  S  operating  in  backup 
mode,  some  changes  in  interrogator  software  are  likely  to  be  required  for  the  Mode  S  to 
acknowledge  the  Mode  4  enable,  begin  modulating  RF  with  the  Mode  4  pulses,  and  to  send  the 
appropriate  quantized  video  and  mode  triggers  back  to  the  ARSR-4. 

Protocol  Analyzer  Tests 

Table  4. 1.2-1  shows  the  results  of  tests  on  some  of  the  ARSR-4  status  message  bits  sent  to  Mode 
S.  The  test  method  used  to  produce  the  status  change  is  also  included  in  the  table. 

Conclusions 

a.  The  ARSR-4,  as  described  in  the  ARSR-4  to  Mode  S  ICD,  will  not  interface  with  the  Mode 

5  in  its  present  configuration. 

b.  Insufficient  time  (150  ms)  is  allowed  by  the  ARSR-4  for  loss  of  DCE  Ready  on  the 
interface.  DCE  Ready  can  be  dropped  during  Mode  S  in  channel  recoveries  (which  can  take  up  to 
1  second).  The  loss  of  DCE  Ready  for  more  than  150  ms  can  trigger  a  series  of  unnecessary 
reconfigurations  in  both  the  ARSR-4  and  the  Mode  S. 

c.  The  use  of  ARSR-4  and  Mode  S  status  message  loopback  is  most  likely  inadequate  for  fault 
detection  in  the  data  link  layer  of  the  interface  due  to  the  infrequent  occurrence  (once  per  scan)  of 
the  status  message. 

d.  The  Mode  S,  as  presently  configured,  does  not  support  transition  into  and  out  of  Mode  4 
operation. 

e.  The  results  of  the  simulated  protocol  analyzer  tests  revealed  that  ARSR-4  status  is  not 
correctly  reported  to  Mode  S  for  some  of  the  status  bits. 
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TABLE  4. 1.2-1.  ARSR-4  /  MODE  S  STATUS  MESSAGE  TESTS 


Status  Bit 

Description 

TestMethod 

Results 

ANDRAL 

Antenna  Drive  Alarm 

Alternately  turned  off  drive  motors 

Fail 

ANTALA 

Antenna  Alarm 

Induced  alarm  througli  threshold 
adjustment. 

Fail 

APGONL 

APG  Online 

Changed  online  APG 

Pass 

AZALA 

Azimuth  Alarm 

Induced  APG  alarms  through  threshold 
adjustment 

Pass 

BETAPR 

Beacon  Target 

Processor  Status 

Changed  online  Processor 

Pass 

DEFKA 

Default  Ka 

Disconnected  J2  and  J12  on  Data 

Processor 

Pass 

DPALA 

Data  Processor  Alarm 

Unterminated  port 

Pass 

DPRIST 

Data  Processor  Radar 
Interface  Status 

Put  Radar  Interface  Board  into  REPR 

Pass 

DPTOYS 

Data  Processor  TOY 
status 

Cycled  power  to  TOY  clock 

Fail 

FRSOST 

Frequenc}'  Source  Status 

Frequency  Generator  B  to  REPR,  back  to 
STBY 

Pass 

HNBO 

1/2  nm  beacon  offset 

Enabled/disabled  half  mile  beacon  offset 

Pass 

MPSCOM 

MPS  Communications 

Unterminated  port 

Fail 

POLCHA 

Polarization  Change 

Change  from  LP  to  CP 

Pass 

RDRALA 

Radar  Alann 

Induced  IF  RCVR  Power  Supply  alann 
through  threshold  adjustment. 

Fail 

RDSYST 

Radar  System  Status 

Induced  alarms  tlnough  threshold 
adjustment 

Fail 

SPALA 

Signal  Processor  Alarm 

Induced  alarm  through  threshold 
adjustment 

Pass 

SPSTAT 

Signal  Processor  Status 

Put  Sync  B  in  REPR  then  STBY 

Fail 

SUM40N 

Supennode/Mode  4  only 

Toggled  between  Supennode  and  Mode  4 
Only. 

Pass 

SYSCON 

System  Control 

Transferred  system  control  from  LDC  to 
MDT 

Pass 

TRANOO 

Transmitter  On/Off 

Toggled  RF  on/off 

Fail 

TXSTAT 

Transmitter  Status 

Put  Preamp  2  into  REPR;  Induced  alarms 
through  threshold  adjustment 

Pass 

VLDRST 

Vault  Door  Status 

Alternately  opened/closed  vault  doors 

Fail 

WXSTAL 

Weather  Station  Online 
Alarm 

Disconnected  J2  and  J12  on  Data 

Processor 

Pass 
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Recommendations 

a.  The  ARSR-4/Mode  S  ICD  and  ARSR-4  system  design  should  be  corrected  to  enable 
interface  with  the  Mode  S. 

b.  Incorrect  ARSR-4  status  reporting  should  be  corrected. 

c.  A  full  integration  test  is  recommended  for  the  first  site  which  has  an  ARSR-4  and  a  Mode 
S.  The  test  should  include  data  throughput,  format  verification,  capacity  and  delay,  channel 
switching,  and  Mode  S/Mode  4  compatibility  tests. 

4. 1 .3  Weather  Surveillance  to  RRWDS. 

Purpose 

The  purpose  of  this  test  was  to  verify  that  the  ARSR-4,  when  interfaced  with  the  Radar  Remote 
Weather  Display  System’  (RRWDS),  provides  accurate  weather  information  to  the  NWS  user. 

Test  Objectives 

a.  "Verify  that  the  ARSR-4  analog  log  video  output  is  in  a  form  that  will  permit  the  RRWDS 
digitizer  to  accurately  threshold  to  the  five  weather  data  levels  corresponding  to  the  standard 
NWS  values. 

b.  Verify  that  the  ARSR-4  provides  video,  pretrigger,  and  Azimuth  Reference  Pulse  (ARP) 
and  ACP  data  to  the  RRWDS  at  the  correct  voltages. 

c.  Verify  that  the  ARSR-4,  when  interfaced  with  an  RRWDS,  provides  weather  data  to  the 
end  user  that  is  operationally  suitable  and  effective. 

Test  Description 

The  ARSR-4  weather  test  target  generator  was  used  to  inject  weather  test  targets  (at  RF)  through 
the  ARSR-4  weather  processing  path  and  out  to  the  RRWDS. 

The  RR'WDS  weather  log  video  levels  were  measured  using  an  oscilloscope  at  J95  of  the  ARSR-4 
RCJB  without  any  attenuation  in  the  path.  Weather  test  targets  at  35  decibel  (dB),  43  dB,  48  dB, 
54  dB,  and  60  dB  were  injected  to  verify  video  and  position  characteristics. 

Data  Analysis 

After  the  video,  pretrigger,  ARP,  and  ACP  pulse  characteristics  measurements  were  made, 
RRWDS  alignment  was  attempted  using  the  existing  alignment  procedures.  The  ability  of  the 
ARSR-4  to  supply  weather  data  at  the  proper  NWS  level,  range,  and  azimuthal  position  to  the 
RRWDS  was  measured. 

Results 

Pulse  characteristic  measurements  for  the  ARSR-4  generated  video,  pretrigger,  ARP  and  ACP 
signals  indicated  that  the  ARSR-4  met  specified  requirements.  However,  the  RRWDS  could  not 
be  aligned  with  the  ARSR-4  for  the  following  reasons: 
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a.  For  all  weather  test  target  levels  input,  the  RRWDS  displayed  level  six  weather.  The 
ARSR-4  log  amplitude  video  levels  saturated  the  RRWDS  digitizer  and  the  RRWDS  could  not  be 
aligned  to  the  ARSR-4  output  video  levels.  However,  these  high  video  voltages  met  the  ARSR-4 
specified  requirements. 

ARSR-3  weather  video  voltages  were  measured  in  addition  to  the  ARSR-4  voltages.  A 
comparison  between  the  ARSR-3  generated  (using  the  ARSR-3  weather  test  target  generator) 
weather  video  voltages  and  the  ARSR-4  generated  weather  video  voltages  is  shown  in  figure 
4. 1.3-1.  From  the  figure,  it  is  seen  that  at  Mt.  Laguna,  the  weather  video  levels  out  of  the  ARSR- 
4  were  approximately  8  dB  higher  than  the  ARSR-3  video  levels. 

The  figure  shows  that  even  the  lowest  injected  weather  level  from  the  ARSR-4  produced  a 
greater  log  video  amplitude  than  the  highest  injected  weather  level  from  the  ARSR-3.  Therefore, 
all  ARSR-4  video  levels  were  being  interpreted  by  RRWDS  as  NWS  level  6. 


FIGURE  4.1.3-1.  ARSR-4  AND  ARSR-3  RRWDS  VIDEO  COMPARISON 

b.  After  a  prototype  8-dB  attenuator  was  inserted  into  the  ARSR-4  RRWDS  video  path,  the 
RRWDS  alignment  was  again  attempted  with  the  ARSR-4.  Although  the  ARSR-4  video  voltages 
were  now  closer  to  ARSR-3  levels,  problems  in  the  RRWDS  alignment  procedure  were 
encountered.  The  procedure  calls  for  injection  of  weather  test  targets  at  145  nm,  however,  the 
ARSR-4  injected  weather  test  targets  are  calibrated  at  100  nm. 

c.  There  were  also  problems  aligning  the  weather  video  in  azimuth  on  the  RRWDS  display. 
There  was  an  approximate  30  to  40°  shift  in  the  displayed  weather  on  the  RRWDS  from  the 
azimuth  of  the  injected  target.  Further  investigation  revealed  that  the  ARSR-4  RRWDS  ARP  is 
coincident  with  an  ACP.  An  ARSR-4  contract  modification  will  address  a  solution. 

d.  Inspection  of  the  ARSR-4  generated  RRWDS  weather  video  on  an  oscilloscope  revealed 
that  BIT  video,  beyond  the  maximum  range  of  the  radar  and  RRWDS,  is  present  in  the  RRWDS 
video.  This  BIT  information  must  be  gated  out  of  the  video  through  RRWDS  alignment. 
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e.  The  RRWDS  indicated  buffer  overflow  alarms  (Errors  46  and  47)  when  interfaced  with  the 
ARSR-4.  It  is  suspected  that  these  alarms  are  caused  by  the  extended  range  of  the  ARSR-4  over 
the  ARSR-3. 

Due  to  the  inability  of  the  ARSR-4  to  interface  effectively  with  the  RRWDS,  and  the 
decommissioning  of  the  RRWDS  at  the  ARTCC,  the  user  participation  section  of  the  test  was  not 
completed. 

Conclusions 

a.  The  ARSR-4,  in  its  present  form,  does  not  integrate  effectively  with  the  RRWDS.  The 
weather  video  voltage  levels  are  too  high  for  the  RRWDS  to  handle. 

b.  The  existing  ARSR-3/RRWDS  alignment  procedures  do  not  apply  to  RRWDS  alignment 
with  the  ARSR-4. 

c.  The  RRWDS,  when  interfaced  with  the  ARSR-4,  does  not  display  weather  at  the  correct 
azimuth  due  to  the  coincidence  of  the  ARSR-4  generated  ARP  with  an  ACP.  A  contract 
modification  has  been  issued  to  address  the  solution  to  this  problem. 

d.  Additional  BIT  information  is  present  in  dead  time  in  the  ARSR-4  video  sent  to  the 
RRWDS.  If  not  gated  out  during  RRWDS  alignment,  this  BIT  video  will  be  displayed  as  false 
weather  on  the  RRWDS  display. 

e.  The  impact  (if  any)  of  RRWDS  buffer  overflow  alarms  (Errors  46  and  47)  on  operation  is 
unknown.  The  errors  may  be  present  due  to  the  extended  operating  range  of  the  ARSR-4  (as 
compared  to  the  200-nm  ARSR-3). 

f  The  operational  suitability  and  effectiveness  were  not  evaluated  by  the  end  users  due  to  the 
inability  to  establish  the  interface  and  the  lack  of  a  commissioned  RRWDS  at  the  ARTCC. 

Recommendations 

a.  Available  Commercial-Off-The-Shelf  (COTS)  attenuators  can  be  used  to  reduce  present 
ARSR-4  weather  video  levels  to  usable  levels  for  the  RRWDS.  AOS-230  is  pursuing  this 
solution. 

b.  RRWDS  alignment  procedures  should  be  updated  to  reflect  the  differences  in  calibration 
ranges  between  the  ARSR-3  and  the  ARSR-4  and  the  gating  of  BIT  video  out  of  the  ARSR-4 
generated  video. 

c.  After  the  azimuth  problems  are  corrected  via  the  contract  modification,  the  RRWDS 
integration  with  the  ARSR-4  should  be  retested  with  participation  from  the  end  users.  At  that 
time  any  operational  effects  of  RRWDS  buffer  overflow  errors  can  be  assessed. 


31 


4.1.4  Surveillance  to  SQCC/FACSF ACS. 


Purpose 

This  test  was  designed  to  verify  that  the  ARSR-4  functionally  and  physically  interfaces  with  the  SOCC 
and  FACSFAC  in  accordance  with  USjAF  and  Navy  operational  requirements. 

ACT-310  performed  tests  to  evaluate  SOCC  status  message  bit  operation.  The  results  of  these 
tests  are  included  in  this  section.  The  results  for  the  remaining  SOCC  and  FACSFAC  tests, 
performed  by  the  USAF  and  the  Navy,  are  not  presented  in  this  report. 

Test  Objective 

Verify  that  the  status  transmitted  in  the  military  formatted  messages  accurately  reflect  the  status  of  the 
ARSR-4. 

Test  Description 

Faults  were  induced  and  reconfigurations  made  to  the  system  to  exercise  each  bit  in  the  status  message. 
Data  were  collected  from  user  ports  AFl  and  AF2  (configured  to  output  USAF  status  messages)  using 
the  IRES  recorder. 

Data  Analysis 

The  data  were  analyzed  using  IRES.  The  SOCC  status  message  was  examined  with  the  SHOWPCS 
and  SHOWSTAT  programs  to  verify  that  the  information  provided  reflects  the  true  status  and  the 
proper  configuration  of  the  ARSR-4. 

Results 

The  four-word  SOCC  status  message  contains  24  bits  to  indicate  ARSR-4  status.  Twenty-two  bits 
were  exercised  during  the  test.  Table  4. 1 .4-1  contains  the  test  method  used  and  the  result  for  each  bit. 

Of  the  22  SOCC  status  bits  tested,  19  functioned  as  expected.  The  ARSR-4  failed  to  generate  expected 
status  for  three  of  the  bits  when  the  system  configuration  was  changed  or  when  faults  were  introduced 
into  major  subsystems.  Two  bits  (M4PRST,  KGSTAT)  could  not  be  verified  due  to  the  configuration 
at  the  Mt.  Laguna  site,  test  setup,  or  Government  Furnished  Equipment  (GFE)  not  present  at  the  site. 

Conclusions 

Nineteen  of  the  22  status  bits  tested  operated  as  expected.  The  SPSTAT,  M4INOR,  M4ALA  failed  to 
operate  as  expected. 

Recommendations 

The  USAF  and  United  States  Navy  should  evaluate  the  operational  significance  of  these  results. 
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TABLE  4. 1.4-1.  SOCC  STATUS  MESSAGE  TEST  RESULTS 


Bit 

Test  Method 

ReMt 

HNBO 

Enabled,  tlien  disabled  1/2  nm  oflFset. 

Pass 

POLCHA 

Toggled  between  LP  and  CP 

Pass 

SUM40N 

Toggled  between  supennode  and  Mode  4  only  operation. 

Pass 

MODALA 

Disconnected,  tlien  reconnected  modem  cable  in  RCJB. 

Pass 

SRTQCA 

Disabled  tlie  search  RTQC  on  menu  5.2.8.  Ten  scans  later,  enabled  tlie  RTQC. 
Tlie  SRTQCA  bit  was  set  approx,  seven  scans  after  tlie  RTQC  was  disabled.  Tlie 
bit  was  reset  approx,  six  scans  after  the  RTQC  w^as  reenabled. 

Pass 

BETAPR 

Placed  all  reconfigurable  elements  of  beacon  channel  B  to  REPAIR.  Removed 
mode  pair  trigger  input  to  die  RCJB  to  induce  BRTQC  alann. 

Pass 

BRTQCA 

Placed  all  reconfigurable  elements  of  beacon  cliannel  B  to  REPAIR.  Removed 
mode  pair  trigger  input  to  die  RCJB  to  induce  BRTQC  alann. 

Pass 

BOFA 

Recorded  data  on  ports  AFl  and  AF2  at  4800  baud.  Set  die  Time  in  Storage 
(TIS)  to  minimmn.  Disconnected,  dien  reconnected  cable  at  J28  (AFl) 

Pass 

USRALA 

Recorded  data  fi'om  ports  AFl  and  AF2  at  4800  baud.  Set  die  Time  in  Storage 
(TIS)  to  minimum.  Disconnected,  dien  reconnected  cable  at  J28  (AFl) 

Pass 

VLDRST 

Opened,  dien  closed,  Mode  4  safe  doors. 

Pass 

M4CONT 

Toggled  Mode  4  control  between  SOCC  and  LDC  via  LDC/SOCC  switch  in  safe 
A. 

Pass 

BOISTAT 

Toggled  power  for  the  KIR  in  safe  A. 

Pass 

M4PRST 

Not  Tested 

FRSOST 

Placed  Sync.  B  into  REPR  Placed  Frequency  Generator  Diplex  Oscillator  B  into 
REPR.  Grounded  TP78  on  the  RRWDS  board. 

Pass 

DEFKA 

Disconnected,  dien  reconnected  die  weadier  station  at  top  of  DP,  cabinet. 

Pass 

M4INOR 

Created  an  inliibit  zone  at  menu  5.5.5.  Manually  interrogated  widi  LDC  toggle 

Fail 

M4ALA 

switch  for  360  deg.  Ten  scans  later,  interrogated  witii  LDC  pushbutton.  Ten  scans 
later,  cleared  die  inhibit  zone.  Data  showed  diat  M4INOR  did  not  indicate  diat 
360  operation  was  inhibited  any  time  in  die  recording.  M4ALA  did  not  indicate 
an  attempt  to  interrogate  in  an  inhibit  zone. 

Fail 

RCVSTA 

Induced  soft  and  hard  alarms  on  LNA  #10  through  threshold  changes. 

Pass 

DPRIST 

Loaded  blank  clear  day  map  and  clianged  Wx  STC  stop  range  to  minimum  value 
to  induce  RIB  alarms. 

Pass 

SPSTAT 

Induced  Permanent  Echo  (PE)  alarm  in  Sync.  A.  SPSTAT  remained  at  100% 
operational. 

Fail 

TXSTST 

Clianged  diresholds  to  induce  soft  and  liard  alanns  for  transmitter  Preamp  #2. 

Pass 

TXLDST 

Enabled  all  lookdown  sectors  (without  lookdown  function  available). 

Pass 

TXABST 

Clianged  direshold  to  induce  a  soft,  dien  a  liard  alarm  in  die  transmitter. 

Pass 

KGSTAT 

Not  Tested 
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4.1.5  ARSR-4  to  Power  Subsystem. 

Purpose 

The  purpose  of  this  test  was  to  assess  the  impact  that  site  power  interruptions  have  on  the  ARSR- 
4  data  sent  to  the  ARTCC. 

Test  Objectives 

a.  Verify  that  the  ARSR-4  provides  the  means  for  maintaining  any  critical  data  necessary  to 
restore  the  system  to  normal  operation  within  100  ms  following  restoration  of  power  when 
primary  power  failure  occurs  for  greater  than  20  ms,  but  equal  to  or  less  than  15  seconds. 

b.  Verify  that  the  restoration  of  normal  operation  is  automatic  and  that  all  operational 
programs,  fixed  and  dynamic  maps,  field  and  site  adjustable  parameter  settings  are  preserved. 

Test  Description 

Configuration 

The  ARSR-4  power  design  includes  an  isolation  transformer  for  control  of  harmonic  distortion. 
However,  the  ARSR-4  design  does  not  provide  the  means  for  an  uninterruptible  supply  of  site 
power  to  the  system. 

The  ARSR-4  is  equipped  with  backup  batteries  for  the  Signal  Processor  and  Data  Processor.  The 
batteries  supply  power  to  these  cabinets  for  up  to  15  seconds  to  maintain  track  data.  Maps,  and 
Site  Adjustable  Parameters  (SAPs)/Field  Adjustable  Parameters  (FAPs)  during  a  short-term 
power  loss. 

Measures  are  also  taken  in  the  ARSR-4  software  to  maintain  the  system  configuration  during 
power  loss.  Upon  detection  of  a  power  loss,  the  safe  data  and  configuration  segments  are  saved 
to  Electrically  Erasable  Programmable  Read  Only  Memory  (EEPROM). 

The  Mt.  Laguna  ARSR-4  power  configuration  included  an  Ingersoll-Rand  backup  engine 
generator,  set  up  to  provide  backup  power  within  10  seconds  after  detection  of  power  loss. 

During  one  of  the  natural  power  losses  at  the  site,  a  digital  control  board  in  the  Ingersoll-Rand 
generator  was  damaged  and  the  generator  was  subsequently  replaced  with  a  Caterpillar  generator. 

Setup 

During  OT&E,  a  BMI40  power  analyzer  was  connected  to  the  primary  of  the  ARSR-4  isolation 
transformer.  The  analyzer  monitored  voltage  and  current  for  each  of  the  three  phases  and 
compared  this  data  to  preset  thresholds.  Under  normal  power  conditions  (monitored  values  within 
thresholds),  the  analyzer  saved  a  status  report  to  disk  at  noon  and  midnight  each  day.  When  a 
power  fluctuation  occurred,  the  analyzer  recorded  more  detailed  data  to  disk  at  the  time  of  the 
event.  During  some  of  the  events,  surveillance  data  was  recorded  using  IRES  connected  to  User  1 
ports  and  ARSR-4  alarm  and  status  data  was  recorded  using  the  MPS  monitor. 
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Power  loss  data  was  collected  from  two  events,  scheduled  and  nonscheduled  power  outages. 
Scheduled  power  outages  were  accomplished  by  turning  off  a  circuit  breaker  (for  approximately 
10  seconds)  and  then  turning  the  breaker  back  on.  The  time  needed  for  the  backup  engine 
generator  to  start  was  noted  along  with  any  ARSR-4  anomalies  during  recovery. 

Nonscheduled  power  outages  were  interruptions  of  power  service  to  the  site.  These  interruptions 
were  most  severe  during  storms  on  Mt.  Laguna.  Several  times,  one  or  more  phases  of  power  were 
dropped.  On  these  occasions,  “brownout”  conditions  were  encountered  when  voltage  levels 
fluctuated  in  and  out  of  thresholds. 

Data  Analysis 

The  reaction  of  the  ARSR-4  to  a  short  term  (<  15  seconds)  power  loss  was  observed.  Any 
anomalies  noted  during  the  events  were  documented  in  the  test  log  book  at  the  radar  site.  These 
observations  were  correlated  with  power  analyzer  data,  MPS  monitor  data,  and  IRES  data  when 
available. 

Results 

During  the  scheduled  power  losses,  the  engine  generator  was  noted  to  start  up  in  less  than  10 
seconds  each  time.  However,  during  one  nonscheduled  event,  a  digital  board  in  the  Ingersoll- 
Rand  generator  was  damaged  and  no  backup  power  was  supplied  to  the  ARSR-4.  The  generator 
was  later  replaced  with  a  Caterpillar  generator. 

The  ARSR-4  recovery  from  both  scheduled  and  nonscheduled  power  loss  was  inconsistent. 
Sometimes  the  system  would  recover  properly,  providing  continuous  stream  of  data  to  the  user 
with  no  hardware  damage  or  false  BIT  alarms.  Other  times,  problems  were  noted.  The  significant 
problems  are  described  below.  It  should  be  noted  that  several  software  builds  were  installed  in  the 
system  throughout  the  test  period.  The  ARSR-4  was  observed  to  fail  power  loss  recovery  for 
tests  conducted  with  various  software  builds  including  the  final  software  build  tested  during 
OT&E. 

Problem  #1  Large  number  of  false  BIT  alarms. 

On  many  occasions,  after  a  short-term  power  loss,  BIT  reported  multiple  false  hard  alarms.  In 
most  of  these  cases,  a  cold  start  (up  to  a  3-minute  site  outage)  was  needed  to  reset  the  alarms. 

Problem  #2  Large  number  of  false  search  reports. 

Occasionally,  the  ARSR-4  would  output  a  large  number  of  false  search  reports  for  up  to  one  scan. 
The  false  alarms  were  displayed  on  the  LDC  and  were  also  sent  to  the  end  user.  Normal  data 
reporting  commenced  after  resynchronization  at  north. 

Problem  #3  Damage  to  hardware  during  power  loss. 

On  two  separate  occasions,  when  one  leg  of  power  was  lost  to  the  site,  hardware  was  damaged  in 
the  transmitter. 
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The  first  case  occurred  on  May  5,  1995.  The  Basic  Measurement  Instruments  (BMI)  power 
analyzer  was  not  connected  at  the  time  of  the  event.  The  power  loss  included  a  brownout 
condition  where  the  voltage  fluctuated.  The  blowers  in  the  four  bay  cabinets  made  a  loud  choppy 
sound,  giving  the  indication  that  a  phase  was  lost.  After  power  was  restored  to  the  site,  BIT 
reported  a  damaged  collector  power  supply  in  transmitter  A.  Further  investigation  confirmed  the 
bad  power  supply. 

Before  the  transmitter  A  collector  power  supply  could  be  replaced,  a  second  power  loss  occurred. 
Again,  a  brownout  condition  was  experienced.  The  ARSR-4  main  breaker  was  turned  off  at  this 
point  to  avoid  further  damage  to  the  equipment.  The  ARSR-3  continued  to  provide  uninterrupted 
service  to  the  end  user.  The  ARSR-3  operates  on  an  uninterruptible  power  supply  (UPS)  in 
conjunction  with  an  engine  generator. 

After  power  was  restored,  2  days  later,  a  switcher  module  in  a  second  collector  power  supply  was 
found  to  be  damaged,  resulting  in  a  soft  alarm  reported  by  BIT.  The  May  5  power  disturbance 
was  the  suspected  cause  of  the  switcher  module  failure. 

The  second  case  occurred  on  May  13,  1995.  The  BMI  power  analyzer  was  connected  to  the 
isolation  transformer  primary  during  this  event.  The  power  disturbance  was  similar  to  the  one 
experienced  on  May  5  (i.e.,  brownout  condition).  Figure  4. 1.5-1  shows  one  snapshot  of  the  BMI 
40  data  recorded  during  the  event.  The  data  shows  the  short-term  drop  of  phase  C-A  voltage 
(upper  trace  in  the  figure)  accompanied  by  a  fluctuating  phase  C  current  (lower  trace  in  the 
figure). 


PHRSE  C-fl  UOLTRGE  SAG  1:0?: 49  PM 


FIGURE  4.15-1.  SITE  POWER  DATA  -  MAY  13,1995 
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The  ARSR-4  was  turned  off  to  avoid  further  equipment  damage.  Two  days  later,  power  was 
restored.  After  power  restoration,  two  additional  problems  were  apparent. 

The  first  problem  concerned  a  hard  alarm  reported  for  the  2: 1  ;8  splitter  in  the  transmitter.  When 
the  splitter  was  replaced,  the  unit  contained  water.  It  was  suspected  that  the  water  entered  the 
transmitter  from  the  exhaust  duct  above. 

Further  investigation  revealed  that  the  louver  motor  did  not  close  the  louver  for  the  exhaust  duct 
when  the  system  power  was  turned  off.  The  louver  motor  battery  was  not  charged.  BIT  does  not 
monitor  this  battery,  therefore,  no  alarms  were  reported  to  the  user. 

After  the  bad  2:1:8  splitter  was  replaced,  BIT/Fault  Isolation  Tests  (FIT)  isolated  a  damaged  bus 
regulator  board  in  the  transmitter. 

Problem  #4  No  backup  battery  status  monitoring. 

During  investigation  into  power  loss  problems  on  February  2,  1995,  the  circuit  breakers  on  the 
Data  Processor  and  Signal  Processor  cabinets  were  turned  off  to  effect  the  power  loss.  The 
ARSR-4  recovered  with  multiple  false  BIT  alarms.  The  RAPPI  display  on  the  LDC  was  also 
erratic.  A  cold  start  (up  to  a  3 -minute  site  outage)  was  required  to  return  the  system  to  normal 
operation. 

From  this  test,  it  was  determined  that  some  of  the  ARSR-4  power  loss  recovery  problems  were 
due  to  uncharged  backup  batteries  for  the  Signal  Processor  and  Data  Processor.  The  reason  for 
the  uncharged  batteries  (either  bad  batteries,  improper  installation,  or  improper  maintenance)  was 
not  determined.  There  is  no  ARSR-4  BIT  monitoring  of  the  backup  battery  voltages,  therefore, 
the  user  was  given  no  information  concerning  the  health  of  the  batteries. 

Problem  #5  Saving  of  incorrect  safe  data  to  EEPROM. 

By  design,  when  the  ARSR-4  senses  a  power  loss,  safe  data  and  configuration  segments  are  saved 
to  EEPROM.  On  one  occasion,  during  a  brownout  condition,  the  data  saved  to  EEPROM  was 
corrupted.  The  corrupted  information  may  be  confusing  to  site  technicians. 

Problem  #6  Increase  of  minor  version  numbers. 

A  less  significant  effect  of  a  power  loss  is  the  increase  in  the  minor  version  numbers  for 
configuration  and  safe  data  segments  on  the  main  RMS  menu.  When  the  safe  data  and 
configuration  segments  are  saved  to  EEPROM,  the  minor  version  numbers  are  increased  for  these 
segments.  Therefore,  if  version  numbers  are  used  as  a  means  to  keep  track  of  the  configuration, 
power  loss  effects  should  be  considered. 

Conclusions 

a.  The  ARSR-4,  as  configured  at  Mt.  Laguna,  did  not  consistently  recover  from  a  short-term 
power  loss. 

b.  The  backup  engine  generator  may  be  damaged  during  a  power  disturbance,  therefore  only  a 
reliable,  tested  engine  generator  should  be  used  with  the  ARSR-4. 
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c.  On  many  occasions,  the  ARSR-4  reported  a  large  number  of  false  BIT  alarms  after  power 
loss.  A  cold  start  (resulting  in  a  3-minute  data  loss  to  the  user)  was  often  required  to  reset  the 
alarms. 

d.  On  several  occasions  after  a  short-term  power  loss,  a  large  number  of  false  search  reports 
were  output  from  the  ARSR-4.  The  condition  was  reset  after  resynchronization  at  north. 

e.  When  one  or  more  phases  of  site  power  are  dropped,  transmitter  hardware  is  often 
damaged.  Although  the  transmitter  hardware  damaged  during  these  events  was  redundant,  the 
ARSR-4  came  dangerously  close  to  losing  full  search  and  weather  capability.  ARSR-4  hardware 
should  not  be  damaged  due  to  power  surges  or  transients. 

f  The  isolation  transformer  designed  on  the  ARSR-4  was  installed  for  the  control  of 
harmonics  into  the  system.  It  was  not  designed  to  provide  protection  from  loss  of  a  phase  of 
power  or  power  surges. 

g.  The  ARSR-3  appeared  unaffected  during  those  natural  power  disturbances  that  caused 
damage  in  the  ARSR-4  transmitter.  The  ARSR-3  is  operated  on  an  UPS. 

h.  There  is  no  mechanism  in  the  ARSR-4  for  automatically  monitoring  the  health  of  the 
backup  batteries  for  the  data  processor  and  signal  processor. 

i.  The  safe  data  and  configuration  segments,  routinely  saved  to  EEPROM  during  a  power  loss 
can  become  corrupted  during  brownout  conditions. 

j.  Minor  version  numbers  will  increment  when  the  ARSR-4  detects  a  power  loss  and  saves 
data  to  EEPROM. 

Recommendations 

a.  The  ARSR-4  should  be  operated  with  an  UPS  in  addition  to  a  reliable  backup  engine 
generator  in  order  to  avoid  most  of  the  problems  described  above. 

b.  There  should  be  improvements  made  to  BIT  in  order  to  monitor  backup  power  supply 
voltages  and  report  any  alarms  via  the  RMS.  An  alternative  solution  would  be  to  increase  the 
frequency  of  scheduled  maintenance  checks  for  the  backup  batteries. 

c.  ARSR-4  documentation  should  reflect  the  fact  that  minor  version  numbers  may  increase 
during  a  power  loss  due  to  the  saving  of  safe  data  and  configuration  segments  to  EEPROM. 
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4.1.6  Surveillance  Coverage. 

Purpose 

This  test  measures  the  primary  and  secondary  radar  detection  capability  throughout  the  specified 
coverage  volume. 

Test  Objectives 

a.  Verify  that  the  ARSR-4  detects  and  reports  targets  through  360°  in  azimuth. 

b.  Verify  that  the  slant  range  coverage  is  from  5  to  250  nm. 

c.  Verify  that  the  ARSR-4  reports  height  on  targets  through  360°  in  azimuth  from  5  to  250 
nm  in  range. 

d.  Verify  that  the  elevation  reporting  coverage  is  from  at  least  +  0.2  to  20°  above  the 
horizontal. 

e.  Verify  that  the  beacon  altitude  coverage  extends  to  100,000  feet  MSL. 

Test  Description 

Target  of  opportunity  data  was  used  for  coverage  analysis.  The  data  was  collected  at  the  CD-2 
ports  using  an  IRES  recorder.  Data  was  also  collected  from  the  commissioned  ARSR-3  at  Mt. 
Laguna  with  an  MX-6A  recorder  during  one  of  the  tests.  Since  the  RCS  of  the  targets  were 
unknown,  no  conclusions  about  the  search  detection  can  be  drawn. 

Three  sets  of  data  were  recorded  for  coverage  analysis.  RUN497  was  performed  on  June  5,  1995, 
at  the  beginning  of  the  OT&E  retest  period.  The  data  was  recorded  at  the  output  of  the  first 
function  tracker  in  the  ARSR-4. 

RUN535  was  performed  on  July  7,  1995.  Data  was  collected  simultaneously  on  the  ARSR-4  and 
the  ARSR-3  (operating  in  simplex).  The  ARSR-4  data  was  collected  at  the  output  of  the  first 
function  tracker.  The  effects  of  changes  to  geocensor  stop  range  SAPs  during  OT&E  regression 
were  analyzed  through  comparison  of  RIJN497  and  RUN535  ARSR-4  data. 

RIJN600  was  performed  on  July  18,  1995,  during  the  certification  flight  check.  The  data  was 
collected  at  the  output  of  the  ARSR-4  second  function  tracker. 

System  Configuration 

SAPs  were  optimized  during  the  first  phase  of  OT&E.  The  parameters  which  have  a  direct 
impact  on  coverage  performance  are  listed  in  this  section.  Unless  stated  otherwise,  these 
parameters  were  consistent  throughout  testing. 

ARSR-4  transmissions  were  blanked  in  the  direction  of  the  ARSR-3  to  avoid  interference  with  the 
operational  radar.  The  blanked  region  spanned  from  326.25°  to  360°.  The  ARSR-3  transmitter 
was  blanked  in  the  direction  of  the  ARSR-4  (from  approximately  160°to  180°). 
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Two  different  methods  were  used  to  disable  beacon  operation  in  the  direction  of  the  ARSR-3 
tower  during  OT&E.  A  beacon  blanker  was  initially  set  up  on  the  ATCBI-5  to  interrupt  mode  pair 
trigger  transmission  to  the  ARSR-4  at  the  blanked  azimuths.  The  blanker  was  effective  in 
eliminating  the  adverse  effects  of  beacon  reflections  from  the  ARSR-3  tower.  However,  the 
interruption  of  timing  signals  to  the  beacon  blanker  during  synchronizer  reconfigurations  caused 
an  error  in  the  blanker  and  loss  of  data.  The  error  would  clear  and  normal  operation  would 
resume  at  the  next  ARP  signal. 

At  the  start  of  OT&E  regression,  the  beacon  blanker  was  disconnected  from  the  ATCBI-5. 

Instead,  a  military  map  was  set  up  in  the  ARSR-4  from  330°  to  359.9°.  Beacon  reports  were 
deleted  in  the  formatter  in  this  region. 

The  ARSR-4  provides  a  lookdown  beam  for  low  elevation  coverage  at  high  sites  (above  6500  feet 
elevation).  However,  this  option  was  not  used  at  Mt.  Laguna  (6238  feet  MSL)  due  to  excessive 
number  of  clutter  false  alarms  with  its  use. 

Additional  site  specific  parameters  effecting  coverage  include  antenna  tilt.  Sensitivity  Time 
Control  (STC)  settings,  and  Geocensor  map  configuration.  The  search  antenna  tilt  was  set  at 
+0.630°. 

STC  was  employed  to  reduce  the  saturating  effects  of  nearby  clutter  returns.  The  STC  slope  and 
stop  range  are  user  adjustable  per  sector  and  beam.  The  slope  was  set  to  12  dB  per  octave  for 
each  sector.  The  STC  stop  ranges  in  nautical  miles  are  shown  in  table  4. 1.6-1. 

The  geocensor  map  (filename  8JLGEO)  was  set  up  during  optimization.  Geocensoring  attenuates 
returns  in  selected  range/azimuth  cells  to  control  false  alarms  from  road  traffic  or  excessively 
strong  point  clutter.  The  map  resolution  is  1/8  nm  by  1.4°  and  extends  from  5  to  126  nm.  Each 
cell  can  have  one  of  eight  possible  thresholds. 

Figure  4. 1 .6-1  shows  the  ARSR-4  geocensor  map  for  Mt.  Laguna.  A  large  geocensor  region  was 
configured  east  of  the  radar  around  the  El  Centro  area.  The  region  spanned  from  approximately 
35  to  100  miles  in  range  and  60°  to  115°  in  azimuth  (i.e.,  sectors  5  through  10).  Geocensoring 
was  used  in  an  attempt  to  suppress  strong  clutter  returns  over  the  desert. 

The  maximum  range  in  each  sector  for  which  geocensor  levels  are  applied  is  user  selectable  via 
SAP/FAPs.  This  range  selection  is  common  to  beams  2  through  5.  The  maximum  range  for  each 
sector  is  shown  in  table  4. 1.6-2. 
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TABLE  4. 1 .6-1 .  STC  STOP  RANGE 
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TABLE  4. 1 .6-2.  GEOCENSOR  RANGE  GATE  BY  SECTOR 


SECTOR 

RANGE 

SECTOR 

RANGE 

SECTOR 

RANGE 

SECTOR 

RANGE 

0 

8 

HH 

16 

24 

126.0 

1 

126.0 

9 

■■ 

17 

25 

126.0 

2 

126.0 

10 

126.0 

18 

126.0 

26 

126.0 

3 

126.0 

11 

126.0 

19 

126.0 

27 

126.0 

4 

126.0 

12 

126.0 

20 

126.0 

28 

126.0 

5 

13 

126.0 

21 

126.0 

29 

126.0 

6 

126.0 

14 

126.0 

22 

126.0 

30 

126.0 

7 

30.0 

15 

126.0 

23 

126.0 

31 

126.0 
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GEOCENSOR  MAP 


Data  Analysis 

Coverage  analysis  was  performed  using  IRES.  The  data  was  first  sorted  into  range,  azimuth  and 
height  order  for  each  scan  using  the  PREPPCS  program.  The  data  was  then  tracked  using 
TRACK,  an  alpha-beta  tracker  in  IRES.  The  QUALIFY  program  then  compared  the  resultant 
tracks  to  a  predetermined  set  of  criteria  (e  g.,  minimum  track  age,  minimum  distance  travelled, 
percent  beacon,  etc.)  to  determine  the  status  of  each  track  (true,  false,  or  unknown). 

The  FILTER  program  separated  the  track  data  into  true  and  false  track  files.  The  true  track  file 
was  then  used  for  coverage  analysis. 

The  true  track  data  was  plotted  using  the  PLOTPCS  and  PLOTRHI  programs.  PLOTPCS 
presents  a  PPI  plot  of  range  versus  azimuth.  These  plots  present  the  minimum  and  maximum 
range  of  coverage  at  all  azimuth  angles.  PLOTRHI  plots  reports  in  a  range  versus  height  format. 
The  radar  antenna  height  and  4/3  earth  curvature  are  taken  into  account.  In  each  plot,  areas  of 
reduced  search  detection  are  apparent  by  a  lower  reinforcement  rate. 

Results 

Figure  4. 1.6-2  presents  a  PLOTPCS  plot  (100  scans)  of  the  true  tracks  during  RUN497.  The 
black  tracks  show  search  reinforced  beacon  reports.  Blue  tracks  represent  beacon  reports  with  no 
reinforcement.  The  blanked  region  is  clearly  shown  spanning  from  326°  to  0°in  azimuth.  From 
the  figure,  it  is  evident  that  the  ARSR-4  provides  good  inner  and  outer  range  coverage  for 
primary  and  secondary  targets  from  0  to  326°  in  azimuth. 

Figure  4. 1 .6-3  shows  an  Range  Height  Indicator  (RHI)  plot  for  RUN  497.  The  plot  shows  that 
the  ARSR-4  provides  adequate  search  and  beacon  detection  at  altitudes  within  its  coverage  range. 
The  reinforced  tracks  show  that  the  ARSR-4  provides  coverage  from  below  the  0°  elevation  angle 
through  30°. 

Inspection  of  figures  4. 1 .6-2  and  4. 1 .6-3  reveal  areas  where  nonreinforced  reports  are  prevalent. 
This  indicates  either  reduced  search  detection  or  terrain  shielding.  In  figure  4. 1 .6-2,  two  areas  of 
reduced  search  detection  are  evident.  The  higher  nonreinforced  rate  in  the  first  area  (to  the  west 
of  the  radai  at  approximately  50  nm),  is  primarily  the  result  of  beacon  detection  on  transponder 
equipped  ships  in  the  San  Diego  harbor.  Reduced  search  detection  in  this  area  is  not  an 
operational  concern. 

The  second  small  region  of  nonreinforced  tracks  is  shown  between  35  and  75  nm  in  range  and  60 
and  120°  in  azimuth.  Figure  4. 1 .6-4  shows  this  area  in  greater  detail.  Comparison  of  figures 
4.1. 6-1  and  4. 1.6-2  shows  that  the  low  search  detection  is  in  the  same  area  as  the  highest  levels  of 
geocensoring. 

To  improve  search  detection  in  this  area,  the  maximum  range  for  geocensoring  in  sectors  6 
through  9  was  decreased  on  June  27,  1995.  This  effectively  reduced  the  attenuation  in  the  area  of 
concern.  The  new  values  are  shown  in  table  4. 1.6-3. 
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FIGURE  4. 1.6-3  RUN497  PLOTRHI  COVERAGE  -  100  SCANS 
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TABLE  4. 1.6-3.  GEOCENSOR  STOP  RANGE  CHANGES 


SECTOR 

RANGE 

(lun) 

6 

40 

7 

25 

8 

25 

9 

25 

After  the  geocensor  stop  range  changes,  a  second  test  (RUN  535)  was  performed  on  July  7,  1995. 
Figure  4. 1.6-5  plots  the  beacon  only  and  reinforced  reports  for  RUN  535  in  the  area  to  the  east  of 
the  radar.  The  data  was  recorded  for  approximately  1  hour  and  20  minutes.  The  figure  shows 
many  beacon  only  tracks,  indicating  low  search  detection  in  the  area. 

Figure  4. 1.6-6  shows  an  RHI  plot  for  the  region  where  the  coverage  hole  exists.  The  vast  majority 
of  nonreinforced  reports  are  shown  below  zero  degree  elevation.  Terrain  shielding  most  likely 
contributes  to  the  lower  search  detection  in  this  area.  Excessive  geocensoring  (needed  to  control 
the  false  alarm  rate)  is  also  a  contributor.  Additional  data  showing  the  effects  of  geocensoring  on 
search  test  targets  can  be  found  in  the  Surveillance  Capacity  and  Delay  section  of  this  report. 

RUN  535  contained  data  recorded  simultaneously  from  the  ARSR-4  and  ARSR-3.  Figure  4.1.6-  / 
plots  ARSR-3  reports  in  the  area  to  the  east  of  the  radar.  The  ARSR-3  (operating  in  simplex) 
revealed  the  same  reduced  detection  as  the  ARSR-4. 

Comparison  of  figure  4. 1.6-7  with  4. 1.6-5  shows  that  the  ARSR-4  beacon  detection  in  the  area 
was  better  than  the  ARSR-3.  Several  solid  ARSR-4  beacon  only  tracks  show  only  sparse  beacon 
detection  on  the  ARSR-3. 

Table  4. 1.6-4  shows  that  the  ARSR-4  output  a  higher  number  of  reinforced  reports  than  the 
ARSR-3  in  the  area  to  the  east  of  the  radar.  The  ARSR-4  leinforcement  rate  is  lower  than  the 
ARSR-3  due  to  better  ARSR-4  beacon  only  reporting.  The  results  show  that  ARSR-4  and  ARSR- 
3  search  detection  were  both  low  over  the  mountains  to  the  east  of  the  radar.  However,  the 
ARSR-4  provided  better  beacon  detection  in  that  region.  Therefore,  it  is  concluded  that  the 
ARSR-4  provides  adequate  coverage  in  that  area  for  operational  use. 


TABLE  4. 1.6-4.  RUN  535  -  ARSR-4  VS.  ARSR-3 


ARSR-4 

ARSR-3 

Beacon  Reports 

5187 

4853 

Reinforced 

3575 

3458 

Beacon  Only 

1612 

1395 

Reinforcement  Rate 

68.9% 

71.3% 
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FIGURE  4.1.B-5  RUN535  ARSR-4  AFTER  GEOCENSOR  CHANGES 
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FIGURE  4. 1.6-7  ARSR-3  COVERAGE 
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RUN  600  data  was  collected  during  the  certification  flight  check  on  July  18,  1995,  The  second 
fiinction  tracker  was  enabled.  This  will  be  the  operational  configuration  for  the  Mt.  Laguna 
ARSR-4.  Figures  4. 1.6-8  and  4. 1.6-9  show  the  search  and  beacon  coverage  for  the  true  tracks 
from  IRES.  The  radar  reinforcement  rate  during  the  test  was  83.5  percent,  indicating  good  search 
and  beacon  detection. 

Conclusions 

a.  The  ARSR-4  provides  the  air  traffic  controller  with  suitable  primary  and  secondary  radar 
data  within  the  required  coverage  volume. 

b.  The  ARSR-4  detects  primary  and  beacon  targets  from  5  nm  to  250  nm.  The  ARSR-4 
provides  a  50  nm  increase  in  range  coverage  when  compared  to  the  ARSR-3. 

c.  The  ARSR-4  provides  coverage  from  0  through  326°  in  azimuth.  The  blanked  area  will  be 
tested  when  the  ARSR-3  tower  is  removed. 

d.  Analysis  of  target  of  opportunity  data  showed  that  the  ARSR-4  provides  coverage  at 
elevation  angles  from  below  0  degrees  to  30°  and  altitude  coverage  to  45,000  feet. 

ft  A  hole  in  primary  detection  .  as  revealed  between  35  and  75  miles  in  range  and  60  and  120° 
in  azimuth.  The  hole  was  caused  by  a  combination  of  excessive  geocensoring  in  the  area  and 
terrain  shielding.  High  levels  of  geocensoring  were  needed  to  control  the  search  false  alarm  rate. 
This  resulted  in  attenuating  the  returns  of  real  targets.  The  ARSR-3  (operating  in  simplex) 
experienced  the  same  loss  of  search  detection  in  the  area.  The  ARSR-4  provided  better  beacon 
detection  than  the  ARSR-3  in  the  area. 

4.1.7  Surveillance  Detection. 

Radar  target  detection  tests  were  divided  into  three  segments.  First,  the  operational  subclutter 
visibility  (SCV)  of  the  ARSR-4  was  measured  by  positioning  a  search  test  target  over  a  near 
saturating  point  of  clutter.  Next,  T-38  test  aircraft  flew  along  a  radial  at  various  altitudes  to  verify 
2.2  squ^tfjneter  detection  requirements.  Finally,  a  Convair  580  test  aircraft  flew  the  air  routes 
within  Mt.  Laguna  coverage  at  minimum  enroute  altitudes  to  ensure  that  the  ARSR-4  detection 
was  acceptable  in  these  areas. 


4. 1 .  / .  I  Subclutter  Visibility. 


Purpose 

Ensure  that  the  ARSR-4  can  adequately  detect  a  moving  target  whose  amplitude  is  well  below  the 
amplitude  of  the  surrounding  clutter. 

Test  Objective 

Determine  the  ARSR-4  subclutter  visibility. 
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FIGURE  4. 1.6-9  RUN  600  ARSR-4  PLOTRHI  COVERAGE  -  100  SCANS 
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Test  Description 

The  Phase  II  Development  Test  and  Evaluation  (DT&E)  SCV  test  was  repeated  during  OT&E  at 
Mt.  Laguna.  The  SCV  measurement  was  performed  once.  The  measurement  was  made  with  the 
25MAY95  build  installed  in  the  system. 

A  near  limiting  point  clutter  source  was  identified  to  the  southeast  of  the  radar  (in  sector  13).  The 
STC  end  range  in  sector  13  was  reduced  from  160  to  80  for  beam  2  to  ensure  that  the  clutter  was 
near  but  not  into  saturation.  The  clutter  amplitude  was  determined  through  adjustment  of  the 
video  level  filters  via  menu  2. 10  on  the  LDC/RMS. 

A  search  test  target  with  a  doppler  velocity  of  500  knots  was  positioned  over  the  clutter  video  on 
the  LDC.  The  second  function  velocity  threshold  was  set  to  zero  to  enable  a  search  RAPPI 
indication  for  the  test  target  on  the  LDC. 

Several  iterations  of  search  test  target  amplitude  adjustment  were  needed  to  determine  the  SCV. 
At  each  test  target  amplitude,  the  blip  scan  for  the  test  target  was  measured  on  the  LDC  RAPPI 
over  a  period  of  ten  scans.  The  SCV  was  the  difference  (in  dB)  between  the  measured  clutter 
amplitude  and  the  search  test  target  amplitude  at  which  a  0.8  blip  scan  was  obtained  for  the  test 
target. 


Results 

The  measured  SCV  was  51  dB.  This  result  compares  favorably  with  the  Phase  II  DT&E  test 
result  of  50  dB. 

Conclusions 

Although  there  is  no  SCV  requirement  in  FAA-2763B,  the  measured  value  indicates  that  the 
ARSR-4  provides  sufficient  detection  performance  in  operational  clutter  environments. 

4. 1.7,2  Primary  Target  Detection  -  2.2  Square  Meter  Target. 

Purpose 

Ensure  thatlhe  ARSR-4  can  detect  a  2.2  square  meter  target  throughout  the  coverage  volume 
with  adequate  beacon idetection- for  Air  Traffic  (AT)  use. 

Test  Objectives 

a.  Verify,  through  dedicated  flight  tests,  that  the  ARSR-4  can  detect  a  2.2  square  meter 
target  at  least  80  percent  of  the  time  at  distances  from  5  to  200  nm. 

b.  Verify  that  the  beacon  percent  detection  for  the  flight  test  aircraft  exceeds  80  percent 
within  the  coverage  range  of  the  radar  (5  to  250  nm). 
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Test  Description 

Detection  requirements  for  a  2.2  square  meter  target  were  verified  during  Phase  II  DT&E  through 
flight  tests  using  a  T-38  test  aircraft.  The  T-38  has  a  radar  cross  section  of  approximately  2.2 
square  meters.  The  T-38  flew  inbound  and  outbound  along  the  3 14°  radial  of  the  Mt.  Laguna 
ARSR-4  at  various  altitudes.  The  flight  radial  is  shown  in  figure  4. 1. 7.2-1. 

Fourteen  T-38  detection  flights  were  performed  between  October  25  and  October  30,  1993.  Table 
4. 1.7. 2-1  shows  the  T-38  flight  tests  performed.  Each  flight  was  designated  with  a  run  number. 
Seven  T-38  flights  were  conducted  between  150  and  235  nm  from  the  radar  at  39000  feet  MSL. 
Two  flights  were  conducted  between  0  and  150  nm  at  19000  feet  MSL.  Five  flights  were 
conducted  between  0  and  200  nm  at  39000  feet  MSL.  ARSR-4  detection  when  operated  in  three 
differing  frequency  modes  (VIP,  Pulse  Agile  Mode  (PAM),  and  Burst  Agile  Mode  (BAM))  was 
measured.  CD-2  data  was  recorded  from  the  ARSR-4  output  ports  with  the  IRES  recorder 
during  each  flight. 


TABLE  4.1. 7.2-1.  T-38  FLIGHT  TESTS 


Run 

Range  (nm) 

Altitude 
(ft  MSL) 

ARSR-4 

Mode 

#  ofRadials 

1,3,4 

150-235 

39000 

VIPl 

8  Inbound 

8  Outbound 

9,  10 

150-235 

39000 

PAM 

6  Inbound 

6  Outbound 

11,12 

150-235 

39000 

BAM 

5  Inbound 

5  Outbound 

13,  14 

0-150 

19000 

VIPl 

5  Inbound 

5  Outbound 

17-21 

0-200 

39000 

VIPl 

5  Inbound 

5  Outbound 

Data  Analysis 

Data  reduction  and  analysis  for  the  detection  tests  were  performed  with  IRES.  First,  each 
recorded  file  was  filtered,  using  the  IRES  FILTER  program,  to  keep  only  the  data  around  the 
radial  of  interest.  The  data  was  then  sorted  into  range,  azimuth,  and  height  order  using  the 
PREPPCS  program. 

Next,  the  flight  test  aircraft  was  tracked  using  SELECT,  a  selective  alpha-beta  tracker  in  IRES. 
SELECT  initiates  track  on  the  beacon  code  of  interest,  but  updates  tracks  on  search  or  beacon 
reports.  Aircraft  turns  were  then  filtered  out  of  the  file  using  FILTER. 

Finally,  PLOTPD  presented  detection  results  in  the  form  of  radar  and  beacon  detection 
histograms.  Each  bar  in  the  chart  shows  the  percent  detection  in  a  5-mile  range  window.  The  80 
percent  detection  line  represents  the  minimum  detection  level  required  for  a  2.2  square  meter 
target. 
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The  data  presented  in  each  histogram  was  smoothed  by  averaging  the  percent  detection  over  three 
range  bins  so  the  detection  for  range  bin  N  is  the  average  of  the  raw  percent  detections  for  range 
bins  N-1,  N,  and  N+1 .  Since  no  requirements  were  specified  for  separate  inbound  and  outbound 
detection  characteristics,  composite  in/out  detection  histograms  were  generated.  - 


Results 

The  composite  radar  and  beacon  percent  detection  histograms  for  detection  flights  from  150-235 
nm  are  shown  in  figure  4. 1 .7.2-2  and  table  4. 1 .7.2-2. 

TABLE  4.1. 7.2-2.  PERCENT  DETECTION,  RUNS  1,  3-4 


Range 

(NM) 

Opp 

Radar 

Hits 

Radar 
Raw  % 

.:  Radar 
Smooth  % 

Beacon 

Hits 

Beacon 

Raw% 

Beacon 
Smooth  % 

150.0 

22 

21 

95 

94 

22 

93 

155.0 

49 

46 

94 

97 

44 

90 

160.0 

47 

,  47 

97 

40 

85 

86 

165.0 

44 

43 

98 

99 

36 

82 

84 

170.0 

47 

47 

99 

85 

83 

175.0 

47 

47 

98 

38 

81 

82 

180.0 

46 

43 

93 

96 

37 

80 

84 

185.0 

46 

44 

96 

94 

42 

91 

85 

190.0 

47 

44 

94 

94 

39 

83 

85 

195.0 

44 

41 

93 

91 

82 

83 

200.0 

49 

43 

88 

94 

41 

84 

84 

205.0 

48 

48 

100 

94 

41 

85 

85 

210.0 

46 

43 

94 

85 

80 

215.0 

44 

39 

91 

31 

79 

220.0 

47 

43 

^  87 

38 

81 

74 

225,0 

'  47 

38 

89 

33 

70 

74 

230.0 

49 

46 

91 

35 

71 

73 

235.0 

43 

43 

96 

33 

77 

69 

240.0 

48 

46 

84 

28 

58 

66 

245.0 

31 

14 

73 

19 

61 

61 

250.0 

6 

2 

33 

0 

5 

83 

0 

The  data  in  figure  4. 1.7. 2-2  showed  good  outer  range  radar  detection.  The  radar  80  percent 
detection  threshold  was  maintained  to  a  range  of  241.9  nm,  well  beyond  the  200  nm  requirement. 

Beacon  percent  detection  exceeded  80  percent  until  21 1.4  nm,  then  dropped  as  the  range  of  the 
test  aircraft  increased.  The  objective  of  80  percent  beacon  detection  to  250  nm  was  not  met  for 
the  flight  test  aircraft.  The  beacon  percent  detection  was  less  than  expected  throughout  the  tests 
due  to  suspected  shielding  of  the  beacon  antenna  on  the  test  aircraft  at  outer  ranges. 

The  percent  detection  histogram  of  the  combined  results  for  RUNS  9  and  10  is  shown  in  figure 
4. 1 .7.2-3  and  table  4. 1 .7.2-3 .  The  graph  shows  acceptable  target  detection  when  the  ARSR-4 
operated  in  BAM.  The  composite  radar  percent  detection  drops  below  80  percent  at  232.2  nm. 
The  beacon  percent  detection  for  RUNS  9  and  1 0  exceeded  80  percent  out  to  23 1 . 1  nm. 
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FIGURE  4. 1.7. 2-2  COMPOSITE  PERCENT  DETECTION.  RUNS  1.  3-4.  VIPl  MODE 
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TABLE  4.1. 7.2-3.  PERCENT  DETECTION,  RUNS  9,  10 


Opp 

Radar 

Hits 

Radar 

Raw 

% 

Radar 

Smooth 

% 

Beacon 

Hits 

Beacon 

Raw 

% 

Beacon 

Smooth 

' 

11 

10 

91 

96 

11 

100 

100 

mam 

17 

17 

100 

98 

17 

100 

100 

msm 

21 

21 

100 

100 

21 

100 

100 

165.0 

17 

17 

100 

100 

17 

100 

100 

170.0 

20 

20 

100 

100 

20 

100 

100 

175.0 

18 

18 

100 

100 

18 

100 

100 

180.0 

18 

18 

100 

100 

18 

100 

98 

185.0 

19 

19 

100 

100 

18 

95 

98 

190.0 

19 

19 

100 

100 

19 

100 

98 

195.0 

18 

18 

100 

96 

18 

100 

100 

200.0 

19 

17 

89 

96 

19 

89 

96 

205.0 

19 

19 

100 

93 

17 

89 

9.3 

210.0 

19 

17 

89 

95 

17 

94 

91 

215.0 

18 

17 

94 

88 

17 

90 

91 

220.0 

20 

16 

80 

89 

18 

100 

95 

225.0 

19 

18 

95 

88 

19 

100 

93 

230.0 

18 

16 

89 

84 

16 

89 

86 

235.0 

19 

13 

63 

75 

13 

68 

69 

240.0 

15 

10 

67 

68 

7 

47 

59 

The  percent  detection  histogram  of  the  results  for  RUNS  1 1  and  12  is  shown  in  figure  4. 1 .7.2-4 
and  table  4. 1. 7.2-4.  The  graphs  show  acceptable  radar  target  detection  when  operating  in  PAM. 
The  composite  radar  percent  detection  drops  below  80  percent  at  214.2  nm.  The  beacon  percent 
detection  drops  below  80  percent  at  23 1 . 1  mn. 

The  percent  detection  histogram  of  the  composite  results  of  RUNS  13  and  14  is  shown  in  figure 
4.1. 7.2-5.  The  ARSR-4  provided  good  detection  which  was  well  above  80  percent  from  5  to  150 
nm.  Beacon  percent  detection  was  close  to  100  percent  throughout  the  coverage  area. 

The  percent  detection  histogram  of  the  composite  results  of  RUNS  17  through  21  is  shown  in 
figure  4. 1 .7.2-6.  The  ARSR-4  provided  good  detection  results  throughout  the  area.  There  is, 
however,  a  drop  in  the  detection  area  between  105  and  115  nm.  The  drop  in  detection  was 
caused  by  geocensoring  in  that  area. 

Conclusions 

The  ARSR-4  exceeded  specification  requirements  for  primary  percent  detection  of  a  2.2  square 
meter  target  for  each  of  the  transmit  fi-equency  modes  and  at  each  altitude  tested. 

The  beacon  detection  performance  for  the  te  st  aircraft  did  not  meet  the  objective  of  80  percent 
detection  to  250  nm.  The  lower,  far  range  beacon  percent  detection  was  suspected  to  be  due  to 
shielding  of  the  test  aircraft  beacon  antenna  during  the  test.  In  addition,  since  these  flights  were 
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FIGURE  4. 1.7. 2-3  COMPOSITE  PERCENT  DETECTION,  RUNS  9-10,  PAM  MODE 


FIGURE  4. 1.7. 2-4  COMPOSITE  PERCENT  DETECTION,  RUNS  11-12.  BAM  MODE 
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performed  at  the  end  of  DT&E,  the  beacon  detection  is  not  representative  of  the  optimized 
system  tested  during  OT&E.  The  beacon  outer  range  coverage  for  the  OT&E  configuration  is 
addressed  in  the  Surveillance  Coverage  section  of  the  report. 


TABLE  4.1. 7.2-4.  PERCENT  DETECTION,  RUNS  11,12 


..RMge 

Opp 

Radar 

Hits 

Radar 

Raw 

% 

Radar 

Smooth 

Beacon 

Hits 

Beacon 

Raw 

% 

Beacon 

Smootli 

% 

14 

13 

93 

93 

13 

93 

98 

27 

25 

93 

94 

27 

100 

99 

29 

28 

97 

96 

29 

100 

98 

165.0 

28 

28 

100 

99 

26 

93 

98 

170.0 

27 

27 

100 

100 

27 

100 

98 

175.0 

27 

27 

100 

99 

27 

100 

99 

180.0 

31 

30 

97 

96 

30 

97 

96 

185.0 

27 

25 

93 

95 

25 

93 

94 

190.0 

29 

28 

97 

93 

27 

93 

91 

195.0 

26 

23 

88 

92 

23 

88 

93 

200.0 

28 

25 

89 

89 

27 

96 

94 

205.0 

28 

25 

89 

87 

27 

96 

96 

210.0 

29 

2  ^ 

83 

81 

28 

97 

96 

215.0 

28 

20 

71 

80 

27 

96 

96 

220.0 

27 

23 

85 

76 

26 

96 

94 

225.0 

27 

19 

70 

75 

24 

89 

93 

230.0 

27 

19 

70 

70 

25 

93 

81 

235.0 

26 

18 

69 

63 

16 

62 

75 

240.0 

12 

4 

33 

58 

8 

67 

63 

56 


TABLE  4.1. 7.2-5.  PERCENT  DETECTION,  RUNS  13  AND  14 


Opp 

Radar 

Radar 

Radar 

Beacon 

Beacon 

Beacon 

(NM) 

Hits  :  : 

-Raw 

Smooth 

Hits 

Ra\v 

Smooth 

O 

% 

5.0 

19 

10 

53 

73 

19 

mm 

29 

25 

86 

82 

29 

BEI 

28 

27 

96 

94 

28 

mm 

20.0 

29 

29 

iOO 

99 

29 

100 

25.0 

30 

30 

100 

98 

30 

100 

30.0 

27 

25 

93 

93 

27 

100 

35.0 

29 

25 

86 

86 

29 

100 

40.0 

29 

23 

79 

87 

29 

100 

100 

45  0 

28 

27 

96 

87 

28 

100 

100 

50.0 

30 

26 

87 

91 

30 

100 

100 

55.0 

28 

25 

89 

91 

28 

100 

100 

60.0 

28 

27 

96 

92 

28 

100 

100 

65.0 

28 

25 

89 

91 

28 

100 

100 

70.0 

29 

25 

86 

87 

29 

100 

99 

75.0 

25 

21 

84 

87 

24 

96 

99 

80.0 

25 

23 

92 

91 

25 

100 

99 

85.0 

26 

25 

96 

96 

26 

100 

100 

90.0 

27 

27 

100 

96 

27 

100 

100 

95.0 

23 

21 

91 

94 

23 

100 

100 

100.0 

27 

24 

89 

93 

27 

100 

100 

105.0 

25 

25 

100 

96 

25 

100 

100 

110.0 

28 

28 

100 

91 

28 

100 

100 

115.0 

23 

16 

86 

23 

100 

100 

120.0 

27 

23 

85 

84 

27 

100 

100 

125.0 

26 

25 

96 

93 

26 

100 

100 

130.0 

28 

27 

96 

96 

28 

100 

100 

135.0 

23 

22 

96 

96 

23 

100 

100 

140.0 

28 

27 

96 

97 

28 

100 

100 

145.0 

25 

25 

97 

25 

100 

100 

150.0 

15 

14 

93 

98 

15 

100 

100 

TABLE  4.1. 7.2-6  PERCENT  DETECTION,  RUNS  17-21 


Range 

: 

Opp 

**■■■;■  Raw 

Radar 

Smooth 

% 

Beacon 

Hits 

Beacon 

Raw 

% 

Beacon 

Smooth 

% 

10.0 

27 

0 

0 

30 

25 

93 

93 

15.0 

30 

17 

57 

52 

28 

93 

92 

20.0 

31 

29 

94 

81 

28 

90 

93 

25.0 

30 

28 

93 

95 

29 

97 

95 

30.0 

34 

33 

91 

96 

33 

97 

96 

35.0 

28 

27 

96 

98 

26 

93 

97 

40.0 

32 

32 

100 

98 

32 

100 

98 

45.0 

28 

27 

96 

98 

28 

100 

100 

50.0 

33 

32 

97 

98 

33 

100 

99 

55.0 

29 

29 

100 

99 

28 

97 

99 

60.0 

31 

31 

100 

100 

31 

100 

98 

65.0 

30 

30 

100 

98 

29 

97 

97 

70.0 

29 

27 

93 

98 

27 

93 

96 

75.0 

30 

30 

100 

96 

29 

97 

96 

80.0 

33 

31 

94 

98 

32 

97 

98 

85.0 

28 

28 

100 

97 

28 

100 

99 

90.0 

32 

31 

97 

98 

32 

100 

98 

95.0 

27 

26 

96 

96 

25 

93 

98 

100.0 

32 

30 

94 

95 

32 

100 

98 

105.0 

29 

28 

97 

92 

29 

100 

99 

110.0 

32 

28 

88 

71 

31 

97 

99 

115.0 

29 

8 

28 

65 

29 

100 

98 

120.0 

30 

23 

77 

64 

29  . 

97 

98 

125.0 

29 

25 

86 

83 

28 

97 

96 

130.0 

30 

26 

87 

86 

28 

93 

97 

135.0 

29 

25 

86 

85 

29 

100 

98 

140.0 

32 

26 

81 

87 

32 

100 

99 

145.0 

30 

28 

93 

89 

29 

97 

98 

150.0 

30 

28 

93 

92 

29 

97 

97 

155.0 

30 

27 

90 

92 

29 

97 

96 

160.0 

29 

27 

93 

92 

27 

93 

97 

165.0 

29 

27 

93 

94 

29 

100 

98 

170.0 

32 

31 

97 

91 

32 

100 

99 

175.0 

29 

24 

83 

90 

28 

97 

97 

180.0 

31 

28 

90 

86 

29 

94 

96 

185.0 

30 

25 

83 

85 

29 

97 

96 

190.0 

30 

24 

80 

82 

29 

97 

96 

195.0 

29 

24 

83 

83 

27 

93 

93 

200.0 

16 

14 

88 

84 

14 

88 

91 

59 


4, 1.7.3  Primary  Target  Detection  -  Routes  and  Fixes. 

Purpose 

Ensure  that  the  ARSR-4  can  detect  aircraft  along  known  air  routes  in  the  Mt.  Laguna  coverage 
volume. 

Test  Objective 

Verify  that  the  ARSR-4  detects  the  test  aircraft  at  least  80  percent  of  the  time  when  flying  at 
minimum  enroute  altitudes. 


Test  Description 

Flight  tests  were  performed  along  defined  air  routes  between  fixes  at  minimum  enroute  altitudes. 
These  flights  simulated  the  actual  traffic  patterns  of  commercial,  general  aviation,  and  military 
aircraft  in  the  area.  The  28JUN94  software  build  was  installed  in  the  ARSR-4  for  the  test. 

A  CV-580  was  the  test  aircraft.  Although  the  RCS  of  the  CV-580  is  approximately  22-square 
meters  (head  on),  the  aspect  of  the  aircraft  relative  to  the  radar  changed  throughout  the  test  and 
no  conclusions  can  be  drawn  concerning  the  detection  of  a  22-square  meter  target. 


Three  flight  tests  were  performed  to  test  detection  along  the  air  routes.  RUN  159  and  RUN160 
were  performed  on  August  10,  1994.  RUN161  was  performed  on  August  11,  1994.  The  run 
numbers,  routes  flown  and  altitudes  are  shown  in  table  4. 1.7. 3-1.  The  aircraft  flew  between  the 
following  fixes:  San  Diego  (SAN),  NIKKL,  Thermal  (TRM),  Blythe  (BLH),  Parker  (PKE), 
Needles  (EED),  Twenty  Nine  Palms  (TNP),  Julian  (JLI),  Imperial  (IPL),  Yucca,  Canno,  and  Bard 
(BZA).  CD-2  data  was  collected  at  the  ARSR-4  user  1  ports  with  IRES. 

TABLE  4.1. 7.3-1.  DETECTION  ROUTES/ALTITUDES  FLOWN 


RljNl59 

RUN160 

RUN  161  1 

Route  y 

Alt. 

Route 

Alt. 

Route 

Alt. 

Froni-To 

(Ft.) 

From-To 

(Ft) 

From-To 

(Ft.) 

SAN-NIKKL 

5000 

SAN-CANNO 

8500 

SAN-JLI 

|nsQ|||| 

NIKKL-TRM 

11000 

CANNO-JLI 

8500 

JLI-TRM 

TRM-BLH 

7000 

JLI-BLH 

7000 

TRM-BLH 

7000 

BLH-PKE 

6000 

BLH-TNP 

8000 

BLH-PKE 

6000 

PKE-EED 

TNP-EED 

8000 

PKE-EED 

6000 

EED-TNP 

EED-PKE 

8000 

EED-TNP 

8000 

TNP-TRM 

PKE-TRM 

9000 

TNP-BLH 

8000 

TRM-JLI 

9000 

TRM-BLH 

8000 

BLH-TRM 

7000 

JLI-IPL 

mBm 

BLH-BZA 

5000 

TRM-PKE 

9000 

IPL-TRM 

HH 

BZA-IPL 

4000 

PKE-TRM 

9000 

TRM- Yucca 

IPL-JLI 

8000 

TRM-JLI 

12000 

Yucca-TNP 

9000 

JLI-NIKKL 

10000 

TNP-TRM 

12000 
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Data  Analysis 

Data  reduction  and  analysis  was  performed  with  IRES.  Each  recorded  file  was  sequenced  into 
range,  azimuth  and  height  order  using  the  PREPPCS  program.  The  flight  check  aircraft  was 
tracked  using  SELECT,  a  selective  tracker  program.  False  tracks  were  subsequently  removed 
with  the  FILTER  program. 

Radar  blip  scan  percentages  for  the  test  aircraft  were  calculated.  The  number  of  radar  reports 
were  counted  and  divided  by  the  total  number  of  opportunities  (i.e.,  the  number  of  scans  that  the 
aircraft  was  flying  along  the  routes).  Those  scans  where  the  test  aircraft  flew  through  the  ARSR-4 
blanked  sector  (330°  to  0°)  were  not  counted  as  opportunities. 

Results 

Figure  4. 1 .7.3-1  shows  the  flight  pattern  of  the  CV-580  for  RUNl  59.  The  ARSR-4  provided 
good  detection  of  the  test  aircraft  along  the  routes  with  the  exception  of  two  locations. 

Search  detection  was  degraded  in  an  area  east  of  the  radar  site  (from  35  nm  to  85  nm  and  90°  to 
115°).  This  loss  of  detection  was  caused  by  large  levels  of  geocensoring  which  were  utilized  to 
reduce  the  search  false  alarm  rate  over  the  desert.  The  geocensor  effects  on  detection  are  further 
discussed  in  the  coverage  section  of  this  report.  Detection  was  also  degraded  in  the  NEEDLES 
area  (125  nm  to  150  nm  between  30°  and  50°).  This  drop  in  detection  was  most  likely  due  to 
screening  by  mountains  in  this  area. 

Table  4. 1.7. 3-2  shows  the  radar  blip  scan  percentages  for  RUNS  159-161.  The  blip  scan 
percentages  calculated  for  a  composite  of  all  data  files  exceeded  80  percent.  Overall,  the  percent 
detection  for  radar  was  at  least  86  percent. 

TABLE  4. 1 .7.3-2.  RADAR  AND  BEACON  DETECTION  FOR  CV-580 


Radar  Hits 

Radar  PD 

\>i)  - 

159 

789 

89 

160 

784 

"6 

161 

806 

93 

Conclusions 

a.  The  ARSR-4  provided  good  search  detection  along  the  air  routes  at  minimum  enroute 
altitudes  except  over  the  desert  to  the  east  of  the  site  and  in  the  NEEDLES  area. 

b.  The  drop  in  detection  over  the  desert  was  caused  by  excessive  geocensoring.  The  effects  of 
geocensor  map  reoptimization  in  July  1995,  to  reduce  detection  loss  in  this  area  are  further 
discussed  in  the  Surveillance  Coverage  section  of  this  report. 

c.  The  drop  in  detection  in  the  NEEDLES  area  is  most  likely  caused  by  shielding  by  mountains 
in  that  area. 
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4.1.8  Primary  False  Alarm  Rate. 


Purpose 

Verify  that  the  false  alarm  rate  is  operationally  acceptable  for  use  in  enroute  ATC. 

Test  Objective 

a.  Verify  that  the  number  of  false  reports  per  scan  at  the  output  of  the  first  function  of  the 
scan-to-scan  correlator  fimction  does  not  exceed  a  total  of  194  from  all  causes. 

b.  Verify  that  the  second  function  reduces  the  false  report  rate  to  10  percent  or  less  of  that  at 
the  output  of  the  first  function. 

Test  Description 

Target  of  opportunity  data  was  collected  at  the  AFl  and  AF2  user  ports  using  IRES.  Three  tests 
measured  the  ARSR-4  false  alarm  rate.  Table  4. 1 .8-1  lists  the  tests  along  with  the  ARSR-4  and 
ARSR-3  configurations. 


TABLE  4.1. 8-1.  FALSE  ALARM  DATA  SETS 


ARSR-4 

TX 

ARSR-4  Mode 

;;|:iARSR^|;|;ii 

ARSR-3TX 

446 

On 

VIP/LP 

No 

Off 

597 

On 

VIP/LP 

Yes 

Simplex 

Run  446  was  performed  overnight  on  May  30,  1995.  The  ARSR-3  was  not  transmitting  during 
the  test.  The  ARSR-4  operated  in  VIPl  mode.  Data  at  the  output  of  the  first  function  tracker  was 
recorded. 

Run  597  contains  200  scans  of  data  recorded  at  the  output  of  the  second  function  tracker.  The 
ARSR-4  operated  in  VIP  mode  with  linear  polarization.  The  ARSR-3  operated  in  simplex. 

Data  Analysis 

The  recorded  data  was  analyzed  using  the  IRES  Track  Quality  Assessment  (TQA)  programs. 
Additional  information  on  these  programs  can  be  found  in  appendix  B.  The  data  was  first  tracked 
using  TRACK,  an  alpha-beta  tracker  in  IRES.  The  QUALIFY  program  then  compared  the 
resultant  tracks  to  a  predetermined  set  of  criteria  (e.g.,  minimum  track  age,  minimum  distance 
travelled,  percent  beacon,  etc.)  to  determine  the  status  of  each  track  (true,  false,  or  unknown). 

The  PLOTTQA  track  editor  program  was  used  to  verify  that  the  true  and  false  status  assigned  to 
the  tracks  by  QUALIFY  was  correct.  Also,  the  unknown  tracks  were  manually  reclassified  as  true 
or  false  after  further  study  using  PLOTTQA.  The  COUNTTRK  program  produced  true  and  false 
report  data  counts. 
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The  FILTER  program  separated  the  true  and  false  reports  into  different  files  and  also  removed  the 
beacon  reports  from  the  data  sets.  The  PLOTSCAN  program  plotted  the  false  search  report 
counts  versus  scan  number.  PLOTPCS  plotted  the  reports  in  a  PPI  format. 

Results 

Figure  4. 1.8-1  shows  the  search  reports  per  scan  for  Run  446  for  an  approximate  12-hour  period 
from  2000  to  0800.  The  plot  includes  both  true  and  false  search  reports.  The  data  shows  a 
reduction  in  report  counts  in  the  early  morning  hours  and  the  subsequent  increase  in  counts  after 
day  break.  The  search  counts  never  exceeded  194  per  scan  for  an  extended  period  of  time. 

The  Run  446  data  was  filtered  to  include  1  hour  of  data  from  0700  to  0800.  The  data  was  then 
tracked  and  qualified  in  IRES.  Figure  4. 1.8-2  shows  the  false  search  reports  per  scan.  The  results 
showed  138  false  search  reports  per  scan  averaged  over  300  scans  at  the  first  function  output. 

This  number  is  well  below  the  specified  194  per  scan.  The  reinforcement  rate  during  the  300  scan 
data  set  was  good  (88.7  percent)  indicating  a  good  search  detection  rate. 

Figure  4. 1.8-3  shows  100  scans  of  the  false  tracks  for  Run  446  in  a  PPI  plot.  The  majority  of  the 
false  search  reports  are  the  result  of  clutter  breakthrough  in  the  desert  (to  the  east  of  the  radar) 
and  in  the  San  Diego  area  (to  the  west). 

Figure  4. 1.8-4  shows  all  search  reports  per  scan  recorded  during  Run  597  (200  scans)  at  the 
output  of  the  second  function  tracker.  Comparison  of  figure  4. 1.8-4  with  figure  4. 1.8-1  shows  a 
significant  reduction  in  the  number  of  search  reports  per  scan  when  the  second  function  tracker 
was  employed. 

The  number  of  false  search  reports  per  scan  for  Run  597  after  tracking  is  shown  in  figure  4. 1.8-5. 
There  were  30  false  search  reports  per  scan  averaged  over  the  200-scan  file.  The  radar 
reinforcement  rate  was  good  (83.3  percent). 

The  false  search  report  count  exceeded  the  10  percent  requirement  out  of  the  second  function 
tracker  (i.e.,  greater  than  19  per  scan).  Some  of  the  false  reports  may  be  due  to  the  operation  of 
the  ARSR-3  in  simplex  during  the  test. 

The  false  reports  for  100  scans  of  RUN  597  (after  IRES  analysis)  are  plotted  in  figure  4. 1.8-6. 
Comparison  of  the  figure  with  figure  4. 1 .8-3  (also  100  scans)  shows  a  noticeable  reduction  in  the 
number  of  false  reports  at  the  second  function  output. 

The  false  reports  at  the  second  function  output  were  more  concentrated  in  the  areas  of  strong 
clutter.  Several  iterations  of  geocensor  map  optimization  were  needed  to  find  the  best 
compromise  between  search  detection  and  false  report  rate,  particularly  in  the  desert  to  the  east  of 
the  radar.  Any  attempt  to  further  reduce  the  false  report  rate  (to  meet  the  “10  percent  of  first 
function”  requirement)  by  increasing  geocensor  levels  in  those  areas  may  adversely  impact  search 
detection. 


64 


FIGURE  4.1.B-1  RUN  446  SEARCH  REPORT  COUNTS  -  FIRST  FUNCTION  OUTPUT 


FIGURE  4.1.B-4  RUN  597  SEARCH  REPORT  COUNTS  -  SECOND  FUNCTION  OUTPUT 
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Reponts  Repor'ts 


FIGURE  4. 1.8-5  RUN597  FALSE  SEARCH  REPORTS  -  SECOND  FUNCTION  OUTPUT 


FIGURE  4. 1.8-6  RUN597  FALSE  SEARCH  REPORTS  -  100  SCANS 
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Controllers  who  observed  primary  false  alarms  (see  section  4.2.1)  indicated  that  the  false  targets 
(output  from  the  second  function)  do  not  have  an  adverse  effect  on  tracking  a  primary  target, 
identifying  a  primary  target,  providing  traffic  advisories,  or  the  overall  control  of  air  traffic. 

Conclusions 

a.  The  search  false  report  rate  measured  at  the  output  of  the  first  function  tracker  was  less 
than  the  specified  194  per  scan. 

b.  As  expected,  the  false  search  report  rate  measured  at  the  output  of  the  second  function 
tracker  was  significantly  reduced  from  the  first  function  rate.  However,  the  second  function  false 
report  rate  exceeded  specification  requirements,  (i.e.,  greater  than  10  percent  of  the  first  function 
false  report  rate). 

c.  The  excess  false  search  reports  at  the  second  function  output  were  due  to  limited 
effectiveness  of  ARSR-4  geocensor  and  second  function  tracking  filters  in  reducing  the  effects 
from  strong  clutter  returns. 

d.  Controllers’  responses  to  questionnaires  indicate  that  the  number  of  false  search  reports 
from  the  ARSR-4  (second  function)  do  not  have  an  adverse  effect  on  the  control  of  air  traffic. 

4,1.9  Surveillance  Resolution. 

Purpose 

Verify  that  the  radar  resolution  is  sufficient  to  enable  positive  separation  using  published 
procedures. 

Test  Objectives 

a.  Verify  that,  between  5  and  200  nm,  the  ARSR-4  resolves  with  a  90-percent  probability, 
two  10-square  meter  Swerling  I  targets  separated  by  2°  in  azimuth  in  the  same  range  resolution 
cell  and  within  2,000  feet  in  altitude  of  each  other. 

b.  Verify  that,  between  5  and  200  nm,  the  ARSR-4  resolves  with  a  90-percent  probability, 
iwo  lO-square  meter  Swerling  I  targets  separated  in  range  by  1/8  nm  while  in  the  same  azimuth 
resolution  cell  and  within  2,000  feet  in  altitude  of  each  other. 

c.  Verify  that,  at  100  nm,  the  ARSR-4  resolves  with  50-percent  probability  two  2.2-square 
meter  RCS  targets  (T-38)  separated  by  1.5°  in  azimuth  in  the  same  range  and  doppler  resolution 
cell  and  within  2000  feet  in  altitude  of  each  other,  while  maintaining  the  specified  azimuth 
accuracy  on  each  target  resolved. 

Data  Analysis 

During  the  week  of  August  1,  1994,  the  10-square  meter  azimuth  and  range  resolution  tests 
which  previously  failed  both  Phase  I  and  II  DT&E  tests,  were  repeated  at  Mt.  Laguna.  Five 
azimuth  resolution  flights  were  conducted  on  August  2,  3,  and  4.  Three  range  resolution  flights 
were  then  performed  on  August  5  and  6.  Sufficient  data  for  both  the  azimuth  and  range 
resolution  tests  were  obtained  through  these  flights. 
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The  resolution  tests  were  conducted  using  two  Convair  580  (CV580)  aircraft;  N85790  and  N92. 
The  CV580  aircraft  have  a  RCS  section  of  approximately  21.9  square  meters.  Both 
Westinghouse  Electric  Corporation  (WEC)  and  the  government  agreed  to  using  these  aircraft  to 
verify  resolution  requirements. 

The  Convair  aircraft  flew  in  holding  patterns  between  85  and  1 10  nm  from  the  radar  at  an  azimuth 
of  approximately  290°.  For  the  azimuth  tests,  the  aircraft  flew  in  parallel  holding  patterns  with  a 
nominal  lateral  separation  of  2.0°  and  0  nm  range  separation.  The  height  difference  was  less  than 
100  feet  during  all  azimuth  resolution  flights.  For  the  range  resolution  flights,  the  CV580  flew  a 
tail  chase  configuration  in  the  same  holding  pattern.  The  aircraft  maintained  a  nominal  range 
separation  of  1/8  nm  with  0°  azimuth  separation.  The  height  separation  was  less  than  300  feet 
throughout  the  range  resolution  tests. 

Each  CV580  was  equipped  with  a  Global  Positioning  System  (GPS)  receiver  and  a  NIKE 
transponder  to  obtain  true  positional  data.  GPS  data  was  recorded  aboard  each  aircraft.  During 
the  azimuth  resolution  tests,  NIKE  data  was  recorded  for  aircraft  N85790.  NIKE  data  was 
obtained  on  aircraft  N92  while  conducting  range  resolution  flights. 

The  GPS  data  was  used  to  determine  the  actual  position  and  separation  of  the  two  aircraft  for 
measuring  range  and  azimuth  resolution.  The  GPS  data  from  each  aircraft  was  differentially 
corrected  to  obtain  a  specified  positional  accuracy  of  1 5  meters.  These  differential  corrections 
were  obtained  from  a  GPS  differential  station  located  at  Mt.  Laguna. 

The  NIKE  system  provides  greater  accuracy  than  the  GPS  and  was  employed  to  verify  accuracy 
requirements  for  targets  resolved.  Since  only  one  NIKE  tracker  was  available,  N85790  was 
tracked  during  azimuth  resolution  flights,  while  N92  was  tracked  during  range  resolution  flights. 

During  the  flights,  data  was  collected  using  the  ARSR-4  data  extraction  capability.  The  azimuth 
and  range  resolution  data  was  reduced  and  analyzed  using  IRES.  The  two  Convair  test  targets 
were  tracked  by  the  IRES  alpha-beta  tracker.  The  tracked  target  reports  were  then  merged  with 
GPS  data  based  on  time.  Percent  resolution  was  then  computed  based  on  the  GPS  reported 
separation  and  the  existence  of  one  (no  resolution)  or  two  (targets  resolved)  radar  reports. 

Results 

Due  to  the  unavailability  of  T-38  (2.2  square  meter)  test  aircraft,  only  the  10-square  meter  flight 
tests  were  conducted  during  OT&E.  Therefore,  only  the  10-square  meter  results  will  be 
discussed  here.  Results  from  phase  I  and  phase  II  DT&E  flight  tests  for  the  T-38  indicated  that 
the  ARSR-4  met  the  smaller  target  resolution  requirement. 

Azimuth  resolution  test  results  are  shown  in  figure  4. 1.9-1  and  table  4. 1.9-1.  Percent  resolution 
was  calculated  by  dividing  the  number  of  times  the  radar  resolved  the  closely  spaced  aircraft  (i.e., 
two  target  reports  output)  by  the  number  of  opportunities.  The  separation  data  samples  were 
grouped  into  1  ACP  wide  azimuth  bins.  The  resolution  was  calculated  for  samples  in  each  bin. 
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There  are  three  plots  shown  in  figure  4. 1,9-1.  The  plot  in  the  left  portion  of  the  figure  shows  the 
resolution  percentage  measured  at  each  azimuth  separation  of  the  two  aircraft.  The  plot  in  the 
upper  right  hand  portion  of  the  figure  shows  the  azimuth  separation  distribution  of  the  data 
samples.  The  plot  in  the  lower  right  hand  portion  of  the  figure  shows  the  error  between  the  radar 
measured  separation  and  the  GPS  measured  separation. 

The  data  samples  used  for  azimuth  resolution  analysis  were  taken  from  cases  when  the  targets 
were  separated  in  range  by  less  than  or  equal  to  28/256  nm  (targets  in  same  range  cell)  and  a 
height  separation  less  than  2000  feet. 

Figure  4. 1.9-1  shows  that  the  resolution  exceeds  90  percent  at  a  separation  of  21  ACPs. 

However,  at  the  specified  separation  of  23  ACPs,  the  resolution  drops  below  90  percent.  Table 
4. 1.9-1  shows  that  83  percent  resolution  is  achieved  at  the  required  23  ACP  separation.  The 
number  of  data  samples  exceeds  100  for  separations  between  19  and  26  ACPs,  providing  a  high 
confidence  in  the  measured  resolution  value.  These  test  results  indicate  that  the  90-percent 
resolution  requirement  is  not  being  achieved  by  the  current  ARSR-4  system. 

To  smooth  the  azimuth  resolution  data  due  to  inherent  radar  inaccuracies,  analysis  was  also 
conducted  with  a  2-ACP  azimuth  bin  size.  Figure  4. 1.9-2  and  table  4. 1 .9-2  contain  the  results  for 
a  2-ACP  azimuth  bin.  The  90-percent  resolution  requirement  is  never  achieved  with  data 
smoothed  for  a  2-ACP  bin  size.  At  the  specified  2.0°  separation  (23  ACPs),  a  linear  interpolation 
between  the  22  and  24  ACP  separations  in  table  4. 1.9-2  indicates  a  resolution  of  88  percent. 

The  range  resolution  test  results  for  a  range  bin  size  of  1/256  nm  are  shown  in  figure  4. 1 .9-3  and 
table  4. 1.9-3.  Data  samples  are  based  on  the  measured  range  separation,  an  azimuth  separation  of 
less  than  10  ACPs  and  a  height  separation  of  less  than  2000  feet.  Figure  4. 1 .9-3  shows  that  90- 
percent  resolution  is  not  achieved  until  a  range  separation  of  34/256  nm,  which  is  greater  than  the 
1/8  nm  (32/256  nm)  requirement.  Ninety-percent  resolution  is  not  maintained  until  the  targets  are 
separated  by  42/256  nm. 

Table  4. 1 .9-3  shows  that  the  range  resolution  at  the  required  1/8  nm  is  88  percent.  The  number 
of  samples  for  the  32/256  nm  separation  requirement  is  43  indicating  good  confidence  in  the 
measured  resolution  percentage.  This  data  shows  that  the  range  resolution  requirement  is  not  met 
by  the  current  ARSR-4. 
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FIGURE  4, 1.9-1  CV580  AZIMUTH  RESOLUTION:  1  AGP  BIN  SIZE 


FIGURE  4. 1.9-2  CV580  AZIMUTH  RESOLUTION:  2  AGP  BIN  SIZE 
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TABLE  4. 1.9-1.  CV580  AZIMUTH  RESOLUTION  1  ACP  BIN  SIZE 


Delta  Azimuth 
(AGP) 

Hits 

Scans  : 

Resolution 

Mean 

STD 

12 

1 

5 

20 

0.000 

13 

1 

10 

10 

0.000 

14 

6 

18 

33 

0.983 

15 

14 

22 

64 

-0.357 

2.437 

16 

15 

23 

65 

-1.400 

4.339 

17 

58 

72 

81 

-0.741 

2.082 

18 

87 

!01 

86 

-1,448 

1.951 

19 

93 

116 

80 

-1.581 

2.267 

20 

110 

135 

81 

-2.236 

2.616 

21 

123 

136 

90 

-2.154 

2.652 

22 

162 

178 

91 

-2.747 

2.836 

23 

137 

166 

83 

-3.161 

2.896 

24 

no 

123 

89 

-3.609 

3.154 

25 

93 

105 

89 

-4.000 

3.923 

26 

93 

111 

84 

-4.849 

3.451 

27 

52 

90 

-4.936 

4.346 

28 

41 

88 

-8.194 

4.048 

29 

87 

-6.423 

4.254 

30 

40 

-4.500 

0.707 

31 

100 

-8.250 

5.852 

32 

50 

-10.000 

0.000 

TABLE  4. 1.9-2.  CV580  AZIMUTH  RESOLUTION  2  ACP  BIN  SIZE 


Hits 

Scans 

Mean 

STD 

6 

2 

15 

13 

-0.500 

0.707 

7 

20 

40 

50 

-0.200 

1.105 

8 

73 

95 

77 

-0.288 

1.419 

.  9 

180 

217 

83 

-0.772 

1.138 

10 

233 

271 

86 

-1.086 

1.346 

11 

299 

344 

87 

-1.488 

1.450 

12 

203 

228 

89 

-1.916 

1.763 

13 

140 

163 

86 

-2.529 

1.898 

14 

62 

71 

87 

-3.806 

2.194 

15 

6 

9 

67 

-3.333 

2.422 

t6 

1 

3 

33 

-5.000 

0.000 
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FIGURE  4. 1,9-3  CV580  RANGE  RESOLUTION:  1/256  NM  BIN  SIZE 


FIGURE  4. 1.9-4  CV580  RANGE  RESOLUTION:  1/128  NM  BIN  SIZE 
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TABLE  4. 1.9-3.  CV580  RANGE  RESOLUTION  1/256  NM  BIN  SIZE 


To  smooth  the  data  points,  the  range  bin  was  adjusted  for  1/128  nm.  The  results  of  range 
resolution  analysis  with  a  1/128  nm  range  bin  are  shown  in  figure  4. 1 .9-4  and  table  4. 1.9-4.  The 
90-percent  resolution  requirement  is  not  achieved  or  maintained  until  the  targets  are  separated  by 
21/128  nm,  which  is  greater  than  the  1/8  nm  (16/128  nm)  requirement.  Table  4. 1.9-4  shows  87 
percent  resolution  at  the  required  16/128  nm  separation.  In  addition  the  sample  size  at  this 
separation  is  79,  providing  a  high  confidence  in  the  measured  value.  This  data  also  shows  that  the 
ARSR-4  falls  short  of  meeting  the  90  percent  resolution  requirement  with  a  1/8  nm  (16/128  nm) 
range  separation. 

TABLE  4. 1.9-4.  CV580  RANGE  RESOLUTION:  1/128  NM  BIN  SIZE 


Delta  Range 
(1/128NM) 

Hits 

Scans 

Resolution 

% 

Mean 

STD 

■  .  x  ,  ■  :  x:; 

5 

11 

95 

12 

7.727 

1.618 

6 

23 

130 

18 

9.826 

4.589 

7 

14 

76 

18 

7.857 

5.304 

8 

24 

58 

41 

7.000 

3.587 

9 

17 

37 

46 

5.118 

2.497 

10 

17 

32 

53 

5.059 

2.657 

11 

36 

51 

71 

3.667 

1.912 

12 

42 

54 

78 

2.381 

2.938 

13 

48 

64 

75 

2.083 

2.061 

14 

54 

66 

82 

1.185 

2.111 

15 

64 

81 

79 

0.250 

2.123 

16 

69 

79 

87 

-0.870 

2.980 

17 

48 

54 

89 

-1.250 

3.727 

18 

38 

43 

88 

-1.368 

3.157 

19 

31 

36 

86 

-1.968 

4.254 

20 

24 

28 

86 

-2.000 

4.086 

21 

33 

36 

92 

-3.667 

4.546 

22 

26 

27 

96 

-2.615 

4.337 

23 

23 

25 

92 

-3.174 

4.745 

24 

17 

18 

94 

-3.765 

6.996 

25 

12 

13 

92 

-0.667 

2.060 

26 

26 

27 

96 

-0.769 

3.713 

27 

20 

20 

100 

-0.200 

2.628 

28 

13 

13 

100 

0.308 

2.562 

29 

12 

12 

100 

-1.333 

4.960 

30 

6 

7 

86 

0.000 

2.191 

31 

9 

9 

100 

2.778 

2.906 

32 

4 

5 

80 

1.000 

2.000 

33 

9 

10 

90 

-0.111 

3.887 

34 

1 

1 

100 

2.000 

0.000 

35 

4 

4 

100 

2.000 

5.033 

36 

5 

5 

100 

0.000 

4.000 

37 

9 

9 

lt)0 

-0.111 

3.333 

38 

14 

15 

93 

-0.571 

2.533 

39 

5 

5 

100 

1.000 

2.828 

40 

5 

5 

100 

0.000 

2.828 

41 

8 

8 

100 

-0.500 

1.414 

42 

6 

6 

100 

-1.333 

3.011 
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Another  anomaly  was  observed  in  the  resolution  data  recorded  for  these  flights.  An  increase  in 
the  allowable  range  separation,  for  targets  which  are  included  in  the  azimuth  resolution  analysis, 
resulted  in  a  significant  reduction  (approximately  25  percent)  in  resolution.  This  indicates  that 
when  two  targets  are  separated  in  azimuth  by  approximately  2°  and  also  have  a  range  separation 
of  greater  than  1/8  nm,  the  targets  are  not  being  resolved. 

Figure  4. 1.9-5  and  table  4  . 1.9-5  show  the  results  of  the  range  resolution  analysis  performed  on  the 
azimuth  resolution  flight  data.  The  azimuth  samples  were  restricted  to  greater  than  22  ACPs  (i.e., 
greater  than  the  required  azimuth  resolution  separation).  The  data  shows  a  hole  in  the  range 
resolution  when  the  targets  are  separated  by  more  than  32/256  nm.  The  resolution  percentage 
again  crosses  the  90  percent  required  level  at  54/256  nm.  Therefore,  when  targets  are  separated 
by  greater  than  the  required  resolution  distance,  the  ARSR-4  fails  to  resolve  the  targets. 

Conclusions 

Phase  I  and  Phase  II  DT&E  test  results  indicated  that  the  ARSR-4  met  the  2.2  square  meter 
azimuth  resolution  requirement  (50  percent  resolution  with  1.5°  separation).  Note  that  this  is  a 
less  stringent  resolution  requirement  than  for  the  10  square  meter  targets. 

The  ARSR-4  does  not  meet  specified  and  operational  azimuth/range  resolution  requirements  for 
the  CV-580.  The  measured  results  showed  88  percent  resolution  beyond  the  specified  separation 
versus  the  required  90-percent  resolution.  This  is  a  minor  problem  and  will  not  be  noticed  by  the 
end  user.  The  use  of  aircraft  with  a  larger  RCS  (21.9  square  meters)  than  the  specified  10  square 
meters  RCS  may  contribute  to  the  lesser  measured  resolution. 

Results  show  that  when  the  two  CV-580  test  aircraft  were  separated  by  greater  than  2°  and  1/8 
nm,  the  measured  resolution  percentage  did  not  meet  the  90-percent  requirement.  The  resolution 
“hole”  extended  to  54/256  nm  (nearly  1/4  nm)  separation  before  90-percent  resolution  was  again 
achieved.  These  results  point  to  a  problem  in  the  ARSR-4  resolution  algorithms. 

Recommendations 

The  operational  significance  of  the  range  resolution  hole  between  1/8  nm  and  1/4  nm  should  be 
evaluated  by  AT  personnel.  If  the  hole  is  deemed  to  be  an  operational  problem,  then  corrections 
should  be  made  to  the  ARSR-4  resolution  algorithms  and  those  fixes  should  be  retested. 
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FIGURE  4. 1.9-5  CV5B0  RANGE  RESOLUTION  -  AZIMUTH  SAMPLES  (22-63  ACPs) 
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TABLE  4. 1.9-5.  CV580  RANGE  RESOLUTION  -  AZIMUTH  SAMPLES  (22-63  ACPs) 


Resolution 


% 

42 

98 

-7.000 

0.000 

33 

91 

-7.467 

2.921 

28 

96 

-9.000 

0.000 

30 

100 

-10.000 

0.000 

36 

97 

-10.543 

2.704 

28 

89 

-10.720 

6.400 

37 

97 

-13.000 

0.000 

27 

96 

-14.000 

0.000 

24 

88 

-14.048 

4.364 

32 

91 

-16.000 

0.000 

16 

88 

-17.000 

0.000 

30 

93 

-18.000 

0.000 

27 

93 

-17.080 

9.600 

23 

78 

-18.667 

5.657 

29 

83 

-21.000 

0.000 

38 

89 

-19.647 

9.754 

30 

73 

-21.909 

5.117 

-19.200 

-25.000 

-21.368 

-19.000 

-28.000 

-19.800 

-30.000 

-23.000 

-11.556 

-28.077 

-18.000 

-19.000 

-28.000 

-17.571 

-3.000 

-5.000 

-6.667 

3.000 

1.200 

-1.222 

4.000 

-5.000 

1.111 

3.286 

1.333 

2.200 

-0.222 

-1.769 

0.000 

-1.571 

2,000 

-1.286 

2.667 

0.600 

0.000 

-0.818 

0.308 


13.586 

0.000 

11.413 

22.627 

0.000 

17.656 

0.000 

14.813 

34.202 

12.017 

21.909 

22.627 

16.000 

24.378 

21.778 

22.978 

17.829 

8.000 

15.640 

15.889 

10.583 

19.596 

2.667 

10.029 

3.266 

7.155 

3.528 

4.438 

6.076 

6.294 

6.532 

3.904 

15.731 

6.693 

4.973 

6.290 

5.282 
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4.1.10  Surveillance  Accuracy. 


Purpose 

The  purpose  of  this  test  was  to  determine  if  the  ARSR-4’s  positional  accuracy  is  sufficient  for 
operational  use. 

Test  Objectives 

a.  Verify  that  the  ARSR-4  provides  single  scan  range  surveillance  information  which  is 
accurate  to  1/16  nm  (rms  values  including  all  bias  and  jitter  errors)  within  the  entire  detection 
envelope. 

b.  Verify  that  the  ARSR-4  provides  single  scan  azimuth  surveillance  information  which  is 
accurate  to  0.176°  (rms  values  including  all  bias  and  jitter  errors),  within  the  entire  detection 
envelope. 

c.  Verify  that  the  beacon  target  processor  reports  at  least  98  percent  of  all  detected 
stationary  targets  at  their  correct  slant  ranges,  plus  or  minus  1/32  nm.  Verify  that  at  least  95 
percent  of  all  moving  targets  with  radial  velocities  of  700  knots  or  less  are  reported  at  their 
correct  (average)  slant  range,  plus  or  minus  1/16  nm. 

d.  Verify  that  the  beacon  target  processor  (BTP)  reports  at  least  80  percent  of  all  detected 
stationary  targets  at  their  correct  azimuths,  plus  or  minus  0. 176°,  when  the  associated  beacon 
radar  is  interrogating  at  10  times  per  degree  of  the  antenna’s  rotation. 

Test  Description 

Azimuth  resolution  flight  test  data  was  analyzed  to  produce  the  ARSR-4  accuracy  results.  The 
flight  test  scenarios  are  described  in  the  Surveillance  Resolution  section  of  this  report. 

Each  aircraft  was  equipped  with  a  GPS  receiver.  A  GPS  ground  station  was  located  at  Mt. 
Laguna.dttring  the  tests.  The  differentially  corrected  GPS  data  (accurate  to  within  1 5  meters)  was 
used  as  the  primary  source  of  positional  truth  in  the  accuracy  analysis. 

Data  Analysis 

Data  was  collected  frcm  the  ARSR-4  data  extraction  subsystem  during  the  test.  The  data  was 
coiiverteo  to  IRES  format  where  it  was  tracked  by  the  IRES  alpha-beta  tracker.  The  tracked 
reports  were  then  merged  with  GPS  data  based  on  time.  The  GPS  reported  positions  were  used  as 
truth  in  comparison  with  the  ARSR-4  reported  positions. 

Results 

Search  range  accuracy  results  are  shown  in  figure  4.1.10-1.  The  figure  shows  that  the  mean  range 
difference  between  the  ARSR-4  and  GPS  was  -8.1/256  nm  with  a  standard  deviation  of  9.5/256 
nm.  The  results  from  these  tests  reveal  an  approximate  1/32  nm  range  bias  in  the  ARSR-4 
reported  range. 
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The  search  range  bias  is  further  verified  through  a  collimation  of  each  aircraft  (N857  and  N92) 
reported  search  range  with  the  reported  beacon  range.  Figures  4. 1 . 10-2  and  4.1.1 0-3  show  the 
radar-beacon  collimation  for  each  test  aircraft.  The  results  are  consistent  with  the  results  in  figure 
4. 1 . 1 0-1,  showing  that  the  radar  is  biased  in  range. 

With  the  added  bias,  the  ARSR-4  search  range  accuracy  was  measured  at  17.6/256  nm.  Although 
this  number  exceeds  the  1/16  nm  requirement,  the  error  in  GPS  range  reporting  must  be 
considered.  The  differentially  corrected  GPS  data  was  specified  accurate  to  within  15  meters 
(2/256  nm).  Therefore,  the  difference  between  the  measured  search  range  accuracy  and  the 
specified  accuracy  falls  within'the  error  of  the  GPS  system.  The  ARSR-4  meets  the  specified 
search  range  accuracy  requirement  (even  with  the  1/32  nm  range  bias). 

Figure  4.1.10-4  shows  the  search  azimuth  accuracy  results  for  each  flight.  The  figure  shows  a 
mean  azimuthal  difference  of  -.  1  ACP  (-.009°)  with  a  standard  deviation  of .  163  ACP  (.014°). 

The  measured  search  azimuth  accuracy  is  well  within  the  0. 176°  requirement. 

Figure  4. 1 . 10-5  shows  the  beacon  range  accuracy  results  for  both  aircraft.  The  figure  shows  two 
accuracy  distributions.  Further  investigation  showed  that  each  distribution  is  contributed  from  one 
of  the  two  test  aircraft.  A  small  range  error  (approximately  1/32  nm)  introduced  by  the 
transponder  on  the  N92  aircraft  i  suspected.  The  data  for  N857  was  filtered  and  the  collimation 
shown  in  figure  4. 1. 10-6.  The  figure  shows  a  mean  range  difference  of  0.09/256  nm  with  a 
standard  deviation  of  3.055/256  nm.  The  measured  beacon  range  accuracy  meets  specified 
requirements. 

Beacon  azimuth  accuracy  results  are  shown  in  figure  4.1.10-7.  The  figure  shows  a  mean  azimuthal 
difference  of-.l  18  ACP  (.010°)  with  a  standard  deviation  of  .198  ACP  (.017°).  The  measured 
beacon  azimuth  accuracy  meets  specified  requirements. 

Conclusions 

The  ARSR-4  meets  the  specified  range  and  azimuth  accuracy  requirements  for  both  search  and 
beacon  processing. 

There  is  an  approximate  1/32  nm  range  bias  between  the  ARSR-4  reported  search  range  and  the 
y^nee:  hr  reDOftcu  ffnui  the  more  accurate  GPS  position. 
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FIGURE  4.1.10-3  SEARCH  RANGE  ACCURACY  VS  BEACON  -  N92  AIRCRAFT 


FIGURE  4.1.10-4  SEARCH  AZIMUTH  ACCURACY  VS  GPS  -  BOTH  AIRCRAFT 
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FIGURE  4.1.10-6  BEACON  RANGE  ACCURACY  VS  GPS  -  N857  AIRCRAFT 
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4, 1  ■  1 1  Beacon  Target  Processor  Performance. 

The  tests  described  in  this  section  were  designed  to  evaluate  the  effectiveness  of  the  ARSR-4 
BTP,  interfaced  with  an  ATCBI-5,  in  detecting  and  processing  replies  from  transponder  equipped 
aircraft.  Each  test  described  below  is  designed  to  evaluate  a  particular  facet  of  the  beacon 
performance.  The  sections  include  Splits  and  False  Reports,  Range  Resolution,  Azimuth 
Resolution,  Code  Validation  and  Code  Accuracy,  and  Pulse  Width  Discrimination. 

The  ARSR-4  beacon  system  performance  (measured  on  targets  of  opportunity)  is  compared  with 
the  ARSR-3  performance  in  the  “ARSR-4  versus  ARSR-3  Comparison”  section  of  this  report. 

Test  Configuration 

A  Mode  S  enroute  beacon  antenna  (type  FA 10250),  in  the  single  array  configuration,  was  chin 
mounted  on  the  Mt.  Laguna  ARSR-4  antenna.  The  beacon  antenna  tilt  was  adjusted  to  zero 
degrees. 

The  ARSR-4  was  interfaced  to  an  ATCBI-5.  The  ATCBI-5  was  operated  in  asynchronous  mode. 
The  beacon  PRF  was  265  Hertz  (Hz).  The  mode  interlace  pattern  was  3/A,  2,  3/A,  C,  The 
ATCBI-5  was  optimized  to  operate  within  standard  blue  sheet  tolerances. 

The  ARSR-4  beacon  Interrogate/Reply  Criteria  SAP/FAPs  were  configured  as  shown  in  table 
4. 1 . 1 1-1 ;  No  runlength  discrimination  sectors  were  enabled  during  the  tests.  The  ARSR-4  beacon 
code  and  garble  tolerance  parameter  settings  are  shown  in  table  4.1.11-2. 


TABLE  4.1.11-1.  ARSR-4  BEACON  DETECTION  PARAMETERS 


Parameter 

Setting 

Alarm  Detection  Window  (N) 

10  (5  to  20) 

Successive  interrogations  w/o  associating  target 

8  (4  to  8) 

reply 

Total  Matching  Replies  to  declare  mode  valid  for 

2  (1  to  6) 

report 

Total  missed  code  matches  before  split  into  two 

6  (1  to  12) 

targets 

Mode 

Hits 

3/A 

3 

2 

10 

3/A  and  2 

10 

C  and  2 

10 

3/A  and  C 

10 

3/A,  2,  and  C 

10 
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TABLE  4.1.11-2.  ARSR-4  BEACON  CODE  AND  GARBLE  TOLERANCES 


ARSR-4  SAP/FAP  Sellings 

Range  Cells 

Bracket  Tolerance 

2 

Code  Data  Sampling  Tolerance 

2 

Garble  Tolerance 

4 

Maximum  Pulsevvidth  Before 

9 

Trail  Edge  Detection 

Most  of  the  tests  described  in  this  section  were  performed  by  injecting  RF  beacon  test  targets  into 
the  ATCBI-5  through  a  test  port  at  the  front  of  the  receiver/transmitter  unit.  A  Sensis  Radio 
Frequency  Beacon  Interrogator  Test  Set  (RFBits)  test  target  generator  injected  test  target 
scenarios  designed  to  verify  beacon  resolution,  code  validation  and  accuracy,  and  pulse  width 
discrimination.  The  directional  and  omni  connections  to  the  antenna  were  disconnected  during  the 
test  target  tests. 

4.1.11.1  Beacon  Splits  and  False  Reports 
Purpose 

Ensure  that  the  ARSR-4  beacon  target  processor  false  report  rate  is  within  acceptable  limits  for 
operation  in  NAS. 

Test  Objective 

Verify  that  the  ARSR-4  outputs  an  acceptably  low  number  of  beacon  splits  and  false  reports. 

Test  Description 

ARSR-4  target  of  opportunity  data  was  collected  at  the  user  1  ports  using  IRES.  At  the  same 
time,  ARSR-3  data  was  collected  using  an  MX-6  recorder.  Data  was  recorded  for  approximately 
1  hour  and  20  minutes  during  the  test  (designated  RUN  535).  The  ARSR-4  operated  with  the 
13JUN95  software  build  for  the  test. 

A  further  comparison  of  the  beacon  performance  between  the  two  radars  can  be  found  in  the 
“ARSR-4  versus  ARSR-3  Comparison”  section  of  this  report. 

Data  Analysis 

Each  data  file  was  analyzed  using  IRES.  The  data  was  first  filtered  to  remove  the  regions  where 
ARSR-4  beacon  operation  was  blanked  in  the  direction  of  the  ARSR-3  tower  (330  to  360°).  The 
PREPPCS  program  sorted  the  data  into  range  and  azimuth  order.  PREPPCS  also  consolidated 
beacon  reports  with  the  same  code  (i.e.,  splits)  and  tagged  the  false  beacon  reports. 

The  FILTER  program  separated  all  beacon  split  reports  into  the  same  file.  The  COUNTPCS 
program  counted  the  number  of  false  beacon  reports  on  each  scan.  The  PLOTPCS  program  was 
used  to  plot  only  the  split  reports  for  each  radar. 
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Results 


Table  4. 1 . 1 1 . 1-1  shows  the  results  of  ARSR-4  and  ARSR-3  beacon  split  analysis  for  RUN  535. 
The  table  shows  the  validated  mode  3/A  and  nonvalidated  Mode  3/A  split  counts  and  the  overall 
percentage  of  splits.  The  ARSR-4  beacon  split  rate  was  nine  times  higher  than  that  of  the  ARSR-3 
during  the  test  with  the  majority  of  the  splits  containing  a  validated  Mode  3/A  code. 

TABLE  4.1.11.1-1.  RUN  535  ARSR-4  VS.  ARSR-3  SPLITS 


1  ARSR-3  Discrete  Beacon  1 

ARSR-4  Discrete  Beacon  | 

Total 

■Beacon 

Split  % 

Total 

Beacon 

Split  % 

60203 

19 

2 

.03 

64717 

163 

11 

.27 

The  ARSR-4  beacon  split  rate  fluctuated  during  the  OT&E  retest  period.  Some  days  the  split  rate 
was  comparable  to  that  of  the  ARSR-3.  On  other  days,  the  ARSR-4  split  rate  was  much  greater 
than  the  ARSR-3  split  rate. 

Figures  4.1.11.1-1  and  4.1.11.1-2  show  the  beacon  split  reports  plotted  in  a  PPI  format  for  the 
ARSR-3  and  the  ARSR-4,  respectively.  The  excessive  ARSR-4  beacon  splits  are  concentrated 
between  50  and  150  nm  in  range  and  between  30“  and  90°  in  azimuth.  This  area  is  in  the 
direction  of  the  Salton  Sea.  Figure  4. 1 . 1 1 . 1-3  shows  a  RHI  plot  of  the  ARSR-4  splits.  From  the 
plot  it  is  evident  that  the  altitudes  of  the  split  reports  vary. 

Conclusions 

a.  The  ARSR-4  has  a  significantly  higher  beacon  split  rate  than  the  ARSR-3.  The  higher  split 
rate  often  exceeds  Quick  Analysis  of  Radar  Sites  (QARS)  tolerances  which  are  used  to  certify  the 
radar  in  NAS. 

b.  Most  of  the  ARSR-4  splits  are  concentrated  in  the  direction  of  the  Salton  Sea.  The 
fluctuating  ARSR-4  split  rate  during  OT&E  retest  may  be  due  to  a  combination  of  environmental 
eircct'5  from  the  Salton  Sea  and  the  wide  beamwidth  of  the  Mode  S  beacon  antenna  at  Mt. 

Laguna. 

Recommendations 

The  cause  for  the  high  ARSR-4  beacon  split  rate  at  Mt.  Laguna  should  be  identified  and 
corrected. 
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FIGURE  4.1.11.1-3  RUN  535  PLOTRHI  -  ARSR-4  SPLITS 
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4.1.11.2  Beacon  Range  Resolution. 


Purpose 

Ensure  that  the  ARSR-4  BTP  resolves  beacon  replies  closely  spaced  in  range. 

Test  Objectives 

a.  Verify  that  two  or  more  beacon  targets  detected  at  the  same  azimuth  but  separated  in 
range  by  more  than  0.7  microseconds  (ps),  are  reported  as  separate  targets. 

b.  Verify  that  the  target  codes  are  validated  and  accurate  when  the  range  separation  of  the 
targets  are  such  that  their  code  or  framing  pulse  positions  overlap  (at  50  percent  amplitude  points) 
by  90  nanoseconds  (ns)  or  less. 

Test  Description 

Table  4. 1 . 1 1 .2-1  describes  the  beacon  test  target  scenarios  used  in  the  range  resolution  test.  Four 
scenarios  were  used.  Each  scenario  was  injected  into  the  ATCBI-5  directional  test  port  using  a 
Sensis  RFBits.  Each  scenario  included  20000  False  Replies  Unsynchronous  In  Time  (FRUIT)  / 
scan.  The  RFBits  beacon  test  set  had  a  20  megahertz  (MHz)  clock.  Therefore,  the  precision  of  the 
range  data  is  50  nsec. 

RANGEOOl,  RANGE002,  and  RANGE003  were  designed  to  measure  the  ability  of  the  ARSR-4 
to  provide  two  separate  beacon  reports  for  reply  trains  separated  by  .6  ps,  .7  ps,  and  .8  ps.  There 
was  no  code  pulse  interference  in  these  scenarios. 

RANGE004  measured  the  ability  of  the  ARSR-4  beacon  target  processor  to  properly  extract  the 
codes  of  injected  replies  when  the  code  pulses  overlapped  by  varying  amounts.  Six  pairs  of  targets 
were  injected,  with  each  pair  at  a  different  azimuth.  The  range  separation  for  targets  in  each  pair 
was  greater  than  the  .7  ps  range  resolution  requirement.  The  amount  of  pulse  overlap  varied  from 
one  pair  to  another. 

Data  Analysis 

Fifty  scans  of  CD-2  data  were  recorded  at  the  user  1  output  ports  for  each  i.ijected  scenario.  The  data 
was  analyzed  using  IRES.  The  data  was  first  filtered  to  include  49  full  scans. 

For  RUNs  287-289,  the  SHOWPCS  and  COUNTPCS  programs  were  used  to  count  the  number 
of  beacon  reports  output  on  each  scan  and  inspect  the  codes  in  the  reports.  For  RUN  290,  the 
data  was  also  filtered  by  azimuth  to  separate  the  data  with  different  pulse  overlaps  during  the  test. 

Results 

Table  4. 1 . 1 1 .2-2  shows  the  beacon  report  counts  for  RUNs  287-289.  On  each  scan,  the  ARSR-4 
output  at  least  12  beacon  reports.  The  Mode  3/A  codes  were  correct  and  validated  100  percent  of 
the  time.  The  ARSR-4  successfully  detected  beacon  replies  separated  by  .7  ps  in  range. 
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TABLE  4. 1 . 1 1 .2-1 .  BEACON  RANGE  RESOLUTION  TEST  SCENARIOS 


jaRUN 

287 


Scenario 

RANGEOOl 


Description _ _ '  :  '  '  a  :  a.  .  ■ 

6  pairs  of  test  targets  \vitlr  each  pair  separated  by  .6  us.  Aziinutli  increments  by 
60  degrees  between  pairs.  Range  movement  =  100  mn/lrr.  Interrogate  on 
modes  3/A,  2, 3/A,  C.  Reply  to  modes  3/A,  2.  Round  Reliability  at  100%. 


288 


RANGE002 


same  as  RANGEOOl  with  .7  us  separation  of  targets  witliin  each  pair. 


289 


RANGE003 


same  as  RANGEOOl  widi  .8  us  separation  of  targets  witliin  each  pair. 


290 


RANGE004 


6  pairs  of  test  targets  witli  each  pair  separated  by  a  different  range  such  tliat  tlie 
framing,  code,  X  or  SPI  pulses  overlap.  Reply  on  Mode  3/A  only.  Range 
movement  =100  nm/lir. 


Target 

Range 

Azimuth 

3/A  Code 

Overlap 

(usee) 

(degrees) 

(nsec) 

1 

617.75 

0 

2510SX 

50 

2 

618.80 

0 

5430SX 

- 

3 

617.75 

60 

7700X 

100 

4 

618.85 

60 

7600S 

- 

5 

617.75 

120 

7777SX 

150 

6 

618.90 

120 

7700 

- 

7 

617.75 

180 

7777SX 

0 

8 

619.65 

180 

7700 

- 

9 

617.75 

240 

7777SX 

None 

10 

619.70 

240 

7700 

- 

11 

617.75 

300 

7777SX 

50 

12 

619.60 

300 

7700 

- 

On  scan  31  of  RUN  287  and  scan  25  of  RUN  289,  the  ARSR-4  output  13  beacon  reports  for  the 
12  targets  injected.  These  two  azimuth  split  reports  had  validated  Mode  3/A  codes.  The  two 
splits  divided  by  the  total  number  of  beacon  reports  (1764)  corresponds  to  a  .1 1  percent  split  rate 
during  the  three  tests. 

TABLE  4.1.11 .2-2.  RUNS  287-289  BEACON  REPORT  COUNTS 


RUN 

Range  Separation 
(usee) 

Average  Reports 

Per  Scan 

287 

.6 

12.02 

288 

.7 

12.00 

289 

.8 

12.02 

Table  4.1.11 .2-3  shows  the  results  for  RUN  290  for  the  RANGE004  scenario.  The  data  was 
filtered  to  include  49  complete  scans  of  data  and  to  isolate  targets  along  each  radial.  Therefore, 
since  there  were  two  targets  injected  along  each  radial,  the  expected  number  of  beacon  reports  on 
each  radial  is  98. 
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TABLE  4.1.11.2-3.  RUN  290  OVERLAPPING  PULSES 


Correct  3/A  Code 

Incoffect  3/A  Code  j 

•  Azimutlt 

:  Pulse 

Beacon 

Val. 

InvaL 

Val. 

Inval; 

(Deg.) 

:  Overlap 

Reports 

(nsec) 

0 

50 

99* 

93 

4 

1* 

1 

60 

100 

98 

56 

24 

0 

18 

120 

150 

98 

25 

36 

0 

37 

180 

0 

98 

94 

4 

0 

0 

240 

None 

98 

98 

0 

0 

0 

300 

50 

!  97 

29 

42 

0 

26 

Since  the  targets  were  separated  by  more  than  the  .7  ps  range  resolution  requirement,  the  data 
shows  a  good  percent  detection.  There  was  one  extra  report  along  the  0°  radial  (denoted  in  the 
table  with  an  asterisk).  The  extra  report  contained  an  incorrect  Mode  3/A  code  which  was 
validated.  There  was  one  missed  detection  on  the  300°  radial. 

With  no  pulse  overlap  (240°),  all  of  the  beacon  reports  contained  the  correct  and  validated  Mode 
3/A  codes.  When  the  trail  edge  of  one  target’s  reply  pulses  were  aligned  with  the  lead  edge  of  the 
second  target’s  reply  pulses  (180°),  all  of  the  beacon  reports  had  the  correct  codes  and  96  percent 
of  the  codes  were  validated. 

Targets  were  positioned  such  that  their  reply  pulses  overlapped  by  50  ns  on  two  different  radials 
(0°  and  300°).  On  the  0°  radial,  95  percent  of  the  reports  had  the  correct  and  validated  code.  On 
the  300°  radial,  only  30  percent  of  the  beacon  reports  contained  the  correct  and  validated  Mode 
3/A  code.  The  lower  validation  percentage  on  the  300°  radial  may  be  due  to  the  test  target  Mode 
3/A  codes  on  that  radial  (i.e.,  7777  and  7700  codes  produce  more  pulse  interference  opportunities 
than  2510  and  5430).  All  of  the  incorrect,  invalidated  reports  on  the  300°  radial  contained  0000 
codes. 

As  expected,  the  radials  whose  targets  had  100  ns  and  150  ns  pulse  overlap  showed  a  lower 
percentage  of  correct  and  validated  codes. 

Conclusions 

a.  The  ARSR-4  beacon  processor  detects  and  reports  two  targets  at  the  same  azimuth  and 
separated  by  0.7  ps  or  more  in  range. 

b.  The  ARSR-4  reports  Mode  3/A  codes  that  are  validated  and  accurate  when  the  code  pulses 
of  the  test  targets  were  overlapped  by  50  ns. 
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4.1.11.3 


Beacon  Azimuth  Resolution. 


Purpose 

Ensure  that  the  ARSR-4  BTP  resolves  beacon  replies  closely  spaced  in  azimuth. 

Test  Objectives 

a.  Verity  that  two  stationary',  identical  targets  which  are  within  0.576  nm  in  range  and 
separated  by  an  absence  of  beacon  replies  for  18  Pulse  Repitition  Time  (PRT)s  are  detected  as 
separate  targets  at  least  95  percent  of  the  time. 

b.  Verify  that  two  detected,  1 1  hit  per  mode  noninterfering  targets  which  are  within  0.05  nm  in 
range,  have  one  or  more  distinguishing  characteristics,  and  are  adjacent  in  azimuth  with  no 
intervening  PRTs  are  resolved  at  least  99.5  percent  of  the  time.  Distinguishing  characteristics 
include  different  Mode  2,  3/A,  or  C  codes. 

Test  Description 

Test  targets  were  injected  into  the  ATCBI-5  to  test  the  ARSR-4  beacon  processor  azimuth 
resolution.  CD-2  data  was  collected  at  the  output  of  the  ARSR-4  using  IRES. 

Table  4.1.1 1.3-1  shows  the  beacon  scenarios  used  in  the  azimuth  resolution  test.  The  AZRESOOl, 
AZRES002,  and  AZRES003  scenarios  each  contained  six  pairs  of  targets.  The  identical  targets  in 
each  pair  were  positioned  at  same  range.  The  azimuth  separation  between  targets  in  each  pair 
varied  from  17  to  19  PRTs  between  scenarios. 

The  round  reliability  of  the  test  targets  was  set  to  76  percent  for  the  AZRESOOl -AZRES003 
tests.  Round  reliability  is  the  probability  of  a  target  replying  to  an  interrogation.  In  the  real  world, 
this  probability  is  less  than  one  due  to  shielding  of  aircraft  beacon  antenna  during  turns, 
interrogations  during  a  transponder’s  dead  time,  etc. 

The  AZRES005  and  AZRES006  scenarios  each  contain  six  pairs  of  targets  which  are  adjacent  in 
azimuth  (i.e.,  no  PRT  separation)  with  one  distinguishing  difference  between  the  targets.  In 
AZRES005,  adjacent  targets  are  at  altitudes  that  differ  by  more  than  100  feet.  In  AZRES006,  the 
adjacent  targets  have  different  mode  3/A  and  2  codes. 

Data  Analysis 

Fifty  scans  of  CD-2  data  were  recorded  at  the  user  1  output  ports  for  each  injected  scenario.  The  data 
was  analyzed  using  IRES.  The  SHOWPCS  and  COUNTPCS  programs  were  used  to  count  the 
number  of  beacon  reports  output  on  each  scan  and  to  inspect  the  codes  in  the  reports. 
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TABLE  4. 1 . 1 1 .3-1 .  BEACON  AZIMUTH  RESOLUTION  TEST  SCENARIOS 


Scenario 

AZRESOOl 


AZRES002 


AZRES003 


AZRES005 


AZRES006 


Description _ 

6  pairs  of  stationary  targets  at  100  nin,  separated  by  18  PRTs  witli  targets  of  each  pair 
identical  in  mode,  code  and  altitude.  Round  Rel  =  76%.  Runlengtl\=31  ACPs 


Mode  3/A  code 
5430SX 
4530SX 
5340SX 
4620SX 
6210SX 
7700SX 


1st  Start  Az 
100  ACPs 
300  ACPs 
500  ACPs 
700  ACPs 
900  ACPs 
1100  ACPs 


2nd  Start  Az 
154  ACPs 
354  ACPs 
554  ACPs 
754  ACPs 
954  ACPs 
1154  ACPs 


same  as  AZRESOOl  witli  start  az  sep  of  53  ACPs  (17  PRT  absence). 

same  as  AZRESOOl  witli  start  az  sep  of  55  ACPs  (19  PRT  absence). 

6  pairs  of  stationary  targets  at  100  mn  witli  targets  of  each  pair  witliin  .05  mn  of  each  otlier 
replying  to  tlie  same  modes  witli  altitudes  differing  by  more  tlian  100  ft. 


M2 

M3 

Azimutli 

Range 

Altitude 

Target 

Code 

Code 

(ACP) 

(nm) 

(KFT) 

1 

4630 

5630 

100 

100.0 

25000 

2 

4630 

5630 

158 

100.03 

25200 

3 

4631 

5631 

300 

100.0 

25000 

4 

4631 

5631 

358 

100.03 

24500 

5 

4632 

5632 

500 

100.0 

25000 

6 

4632 

5632 

558 

100.03 

36500 

7 

4633 

5633 

700 

100.0 

25000 

8 

4633 

5633 

758 

100.03 

4500 

9 

4634 

5634 

900 

100.0 

25000 

10 

4634 

5634 

958 

100.03 

20500 

11 

4635 

5635 

1100 

100.0 

25000 

12 

4635 

5635 

1158 

100.03 

25500 

6  pairs  of  stationary  targets  at  100  nm  witli  targets  of  each  pair 
replying  to  tlie  same  modes  witli  difierent  3/A  or  2  codes. 

M2 

M3 

Azimuth 

Range 

Target 

Code 

Code 

(ACP) 

(run) 

1 

4630 

5630 

100 

100.0 

2 

4630 

5610 

158 

100.03 

3 

4631 

5631 

300 

100.0 

4 

4611 

5631 

358 

100.03 

5 

4632 

5632 

500 

100.0 

6 

4632 

5432 

558 

100.03 

7 

4633 

5633 

700 

100.0 

8 

4733 

5633 

758 

100.03 

9 

4634 

5634 

900 

100.0 

10 

4634 

5630 

958 

100.03 

11 

4635 

5635 

1100 

100.0 

12 

4637 

5635 

1158 

100.03 

94 


Results 

Table  4.1.11.3-2  shows  the  average  number  of  beacon  reports  output  on  each  scan  during  Runs 
292-294.  On  most  scans,  the  ARSR-4  output  12  beacon  reports.  The  Mode  3/A  codes  were 
correct  and  validated  100  percent  of  the  time. 

The  data  were  further  studied  to  determine  the  cause  for  the  “missing  reports”  from  the  data  file. 
In  all  cases,  when  one  target  of  a  pair  was  reported,  it  had  the  correct  azimuth.  This  indicates  that 
the  “missing  reports”  were  not  due  to  lack  of  azimuth  resolution.  The  reports  absent  from  the  data 
file  were  due  to  the  76  percent  round  reliability  imposed  on  the  target  scenarios  (i.e.,  those  targets 
were  never  injected  into  the  ATCBI-5).  The  ARSR-4  successfully  resolved  stationary,  identical 
beacon  replies  for  each  azimuth  separation  100  percent  of  the  time  during  the  test. 

TABLE  4.1.1 1.3-2.  RUNS  292-294  AVERAGE  BEACON  REPORT  COUNTS 


Azimuth 
Separation  (PRT) 

Average  Reports 

Per  Scan 

292 

17 

11.73 

293 

18 

11.77 

294 

19 

11.74 

Table  4.1.1 1.3-3  show's  the  results  when  the  AZRES005  scenario  was  injected.  The  adjacent 
targets  in  each  pair  had  different  Mode  C  altitudes.  The  remaining  characteristics  of  the  targets 
were  identical. 

The  first  column  in  the  table  shows  the  altitude  differences  between  the  adjacent  targets  in  each 
pair.  The  resolution  opportunities  column  contains  the  number  of  times  that  two  targets  were 
injected  into  the  ATCBI-5  at  each  altitude  (the  76  percent  round  reliability  effects  were  removed 
from  analysis). 

The  combined  resolution  percentage  for  all  altitude  differences  was  97.2  percent.  Although  this 
value  does  not  meet  the  99.5  percent  requirement,  the  effects  would  go  unnoticed  operationally 
since  two  real  targets  will  most  likely  have  other  differing  characteristics. 


TABLE  4.1.11.3-3.  RUN  296  -  BEACON  AZIMUTH  RESOLUTION  -  DIFFERENT 

MODE  C  ALTITUDES 


Altitude  Difference 
{Hundred  Feet) 

Resolution 

Opportunities 

Resolution  Percentage 

200 

50 

96 

500 

99 

100 

4500 

47 

100 

11500 

50 

92 

20500 

50 

96 

95 


Table  4.1.1 1.3-4  shows  the  results  when  the  AZRES006  scenario  was  injected.  Six  pairs  of 
adjacent  targets  were  injected  into  the  ATCBI-5  each  scan.  The  targets  in  three  of  the  pairs  were 
identical  except  for  Mode  3/A  code.  The  targets  in  the  other  three  pairs  were  identical  except  for 
Mode  2  code. 

The  data  shows  that  when  the  adjacent  targets  contained  different  Mode  3/A  codes,  the  ARSR-4 
resolved  the  targets  each  time.  All  of  the  Mode  3/A  and  Mode  2  codes  were  correct  and  validated 
for  this  case. 

When  the  adjacent  targets  contained  different  Mode  2  codes  (and  identical  Mode  3/A  codes),  the 
resolution  percentage  dropped  to  96  percent.  Although  this  value  does  not  meet  the  99.5  percent 
requirement,  the  effects  would  go  unnoticed  operationally  since  two  real  targets  will  most  likely 
have  other  differing  characteristics. 


TABLE  4. 1 . 1 1 .3-4.  RUN  297  -  RESPONDING  WITH  DIFFERENT  CODES 


1  Different  Mode  3/A  Codes 

Different  Mode  2  Codes  I 

Resolution 

Opportunities 

Resolution 

Percentage 

Resolution 

Opportunities 

Resolution 

Percentage 

150 

100 

150 

96 

Conclusions 

a.  The  ARSR-4  beacon  processor  effectively  resolves  two  stationary,  identical  targets  which 
are  within  0.576  nm  in  range  of  each  other  and  separated  by  an  absence  of  beacon  replies  for  1 8 
PRTs. 

b.  The  ARSR-4  beacon  processor  effectively  resolved  two  1 1-hit  per  mode  noninterfering 
targets  which  were  within  0.05  nm  in  range  and  differed  only  in  Mode  3/A  or  Mode  C  code. 

4.1.11.4 _ Code  Validation  and  Code  Accuracy. 

Purpose 

Ensure  that  the  ARSR-4  beacon  processor  reports  accurate  beacon  codes  with  a  high  validation 
rate. 

Test  Objectives 

a.  Verify  that  the  ARSR-4  validates  the  beacon  code  information  as  contained  in  the 
aircraft’s  reply  for  Modes  2,  3/A,  and  C  including  SPI  pulses  at  least  95  percent  of  the  time  when 
the  number  of  actual  hits  received  per  mode  is  1 1  or  greater. 

b.  Verify  that  when  the  number  of  hits  per  mode  is  15  or  more,  the  codes  are  validated  at 
least  98  percent  of  the  time. 
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c.  Verify  that  the  validated  codes  are  accurate  at  least  99  times  out  of  100. 

d.  Verify  that  the  ARSR-4  beacon  processor  recognizes  the  false  “phantom”  brackets  which 
can  occur  in  the  closely  spaced  reply  condition  when  nonframing  pulses  in  different  replies  occur 
at  the  framing  interval. 

Test  Description 

CD-2  data  was  recorded  on  the  user  1  ports  with  IRES  while  beacon  test  targets  were  injected  into  the 
ATCBI-5.  Three  different  beacon  test  target  scenarios  were  used  to  measure  the  code  validation 
and  code  accuracy  performance  of  the  ARSR-4  beacon  processor.  Table  4. 1 . 1 1 ,4-1  describes 
each  scenario. 

VAL95SX  tested  the  validation  rate  for  all  reply  bits  including  the  SPI  and  X  bits  when  the  test 
target  runlengths  were  56  ACPs.  Since  the  beacon  Pulse  Repitition  Frequency  (PRF)  was  265  Hz 
and  the  test  targets  replied  to  modes  3/A,  2,  and  C  interrogations,  the  number  of  hits  per  mode  is 
1 1  for  these  scenarios. 

VAL98SX  tested  the  validation  rate  for  all  reply  bits  including  the  SPI  and  X  bits  when  the  test 
target  runlengths  were  77  ACPs.  This  corresponds  to  1 5  hits  per  mode. 

PHANTOMl  tested  the  ability  of  the  ARSR-4  beacon  processor  to  recognize  phantom  cases 
(i.e.,  those  cases  where  the  bracket  pulses  of  one  target  reply  align  with  the  C2  and  SPI  pulses  of 
the  second  target’s  replies.  ARSR-4  contains  six  pairs  of  individual  targets  with  C2-SPI 
interference. 

TABLE  4.1.11.4-1.  CODE  VALIDATION  AND  CODE  ACCURACY  TEST  SCENARIOS 


RUN 

Scenario 

D^cription 

300 

VAL95SX 

Sixteen  spokes  of  ten  targets  each.  Tlie  X  and  SPI  bits  were  set  for  modes  2  and 

3/A.  Target  Rimlengtli  =  56  ACPs.  Round  Reliability  =  100%. 

302 

VAL98SX 

same  as  VAL95SX  except  target  runlengtli  =  77  ACPs. 

303 

PHANTOMl 

6  pairs  of  individual  targets  witli  C2-SPI  pulse  interference. 

Data  Analysis 

The  CD-2  data  was  analyzed  using  IRES.  The  COUNTPCS  and  SHOWPCS  programs  were  used 
to  inspect  the  beacon  report  codes  and  count  the  number  of  reports  with  the  correct  and  validated 
codes. 

Results 

Table  4. 1 . 1 1 .4-2  shows  the  results  when  the  VAL95SX  (56  ACP  runlength)  and  VAL98SX  (77 
ACP  runlength)  scenarios  were  injected  into  the  ATCBI-5.  There  were  160  targets  injected  on 
each  scan.  Data  was  recorded  for  50  scans  during  the  test.  The  results  show  that  the  ARSR-4 
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reported  the  correct  and  validated  code  (including  SPI  bit)  over  99  percent  of  the  time  during  the 
test  when  the  target  runlength  was  56  ACPs  and  100  percent  of  the  time  when  the  test  target 
runlength  was  77  ACPs.  The  asterisks  in  the  table  denote  cases  of  azimuth  splits  during  the  test 
with  the  longer  runlengths. 

TABLE  4.1.1 1.4-2.  VAL95SX  AND  VAL98SX  RESULTS 


:  Gorrect  and  Validate  I 

Target 

Runlength 

(ACPs) 

Targets 

Injected 

.  Mode  3/ A 

Mode  2 

ModeC 

56 

8000 

7978 

(99.7%) 

7966 

(99.5%) 

7971 

(99.6%) 

77 

8000 

8004* 

(100%) 

Table  4. 1 . 1 1 .4-3  shows  the  results  for  the  PHANTOMl  test.  In  each  case,  the  ARSR-4 
successfully  identified  the  C2-SPI  pulse  interference.  The  correct  code  of  one  of  the  targets  in 
each  pair  was  extracted  and  validated.  The  code  of  the  second  target  was  set  to  zero  each  time. 

TABLE  4.1.11.4-3.  RUN  303  PHANTOMl  TEST  SCENARIO 


Beacon 

Targets 

Correct  and  Vdidated  Mode  3/A 

Codes 

Nonvatidated  Zero  Mode  3/A  Codes 

600 

300 

300 

Conclusions 

a.  The  ARSR-4  validates  the  beacon  code  information  as  contained  in  the  aircraft’s  reply  for 
Modes  2,  3/A,  and  C  [including  SPI  pulses]  at  least  95  percent  of  the  time  when  the  number  of 
actual  hits  received  per  mode  is  1 1  or  greater. 

b.  When  the  number  of  hits  per  mode  is  15  or  more,  the  codes  were  validated  at  least  98 
percent  of  the  time. 

c.  The  validated  codes  were  accurate  at  least  99  times  out  of  100. 

d.  The  ARSR-4  beacon  processor  recognizes  the  false  “phantom”  brackets.  The  Mode  3/A 
code  was  successfully  extracted  for  one  target,  while  the  code  was  correctly  set  to  zero  for  the 
interfering  target. 
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4.1.1 1.5  Pulse  Width  Discrimination. 


Purpose 

Ensure  that  the  pulse  width  discrimination  functions  in  the  ARSR-4  beacon  target  processor 
operate  properly. 

Test  Objective 

Verify  that  the  ARSR-4  rejects  beacon  pulses  with  less  than  a  150-ns  pulse  width  and  accepts 
pulses  with  greater  than  300-ns  pulse  width. 

Test  Description 

One  beacon  scenario,  PULSE003,  was  used  to  measure  the  ARSR-4  beacon  pulse  width 
discrimination.  The  scenario  is  shown  in  table  4. 1. 1 1.5-1.  Twelve  targets  were  injected  at  different 
azimuths.  The  bracket  and  code  pulse  widths  remained  constant  for  each  target  reply,  but  varied 
from  one  target  to  another. 

Fifty  scans  of  CD-2  data  were  recorded  at  the  user  1  output  using  IRES  (RUN  243). 

TABLE  4.1.11.5-1.  PULSE  WIDTH  DISCRIMINATION  TEST  SCENARIO 


Scenario 

Description 

PULSE003 

Twelve  individual  targets  injected.  Each  target  reply  lias  tlie  same  pulse  widtli  for  all 
bracket  and  code  pulses. 

Target  Pulse  Width  (nsec) 

Azimuth  (deg) 

1 

50 

30 

2 

100 

60 

3 

150 

90 

4 

200 

120 

5 

250 

150 

6 

300 

180 

7 

350 

210 

8 

400 

240 

9 

450 

270 

10 

500 

300 

11 

550 

330 

12 

600 

355 

Data  Analysis 

The  recorded  data  was  inspected  using  the  IRES  SHOWPCS  and  PLOTPCS  programs. 

Results 

Figure  4.1.1 1.5-1  shows  a  PPI  plot  of  the  beacon  reports  in  RUN  243.  The  data  shows  that 
beacon  replies  were  not  detected  when  the  reply  pulse  width  was  less  than  250  ns.  At  a  250  ns 
pulse  width,  five  beacon  reports  were  output.  For  pulse  widths  greater  than  250  ns,  beacon 
reports  were  output  on  each  scan. 
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FIGURE  4.1.11.5-1  RUN  243 
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Conclusions 

The  ARSR-4  effectively  rejects  beacon  reply  pulse  widths  less  than  250  ns  and  accepts  pulse 
widths  greater  than  300  ns. 

4.1.12  Surveillance  Capacity  and  Delay. 

Purpose 

Ensure  that  the  ARSR-4  can  adequately  process  a  capacity  target  load  within  specified  delay 
times. 

Test  Objectives 

a.  Verify  that,  when  the  ARSR-4  is  not  colocated  with  the  Mode  S  system,  the  overall  data 
delay  from  the  antenna  peak  of  beam  to  report  being  available  at  the  input  to  the  modems  is  1 .5 
seconds  or  less  during  peak  capacity  conditions. 

b.  Verify  that  the  ARSR-4  can  process  and  provide  message  outputs  for  a  steady  state 
maximum  load  of  800  aircraft  returns  within  the  primary  radar  coverage  area. 

c.  Verify  that  the  ARSR-4  can  process  and  provide  message  outputs  for  a  large  sector  peak 
consisting  of  50  aircraft  returns  in  each  of  eight  contiguous  1 1.25°  sectors. 

d.  Verify  that  the  ARSR-4  can  process  and  provide  message  outputs  for  a  small  sector  peak 
consisting  of  20  aircraft  returns  in  each  of  three  contiguous  1.2°  sectors. 

e.  Verify  that  the  ARSR-4  can  process  and  provide  message  outputs  for  a  azimuth  peak  of 
60  aircraft  returns  aligned  in  an  azimuth  radial. 

f  Verify  that  the  ARSR-4  can  process  and  provide  message  outputs  for  a  range  distribution 
peak  of  four  aircraft  returns  within  a  4.5  nm  interval  not  equally  spaced. 

Test  Description 

The  ARSR-4  successfully  completed  extensive  capacity  and  delay  tests  during  DT&E  Software 
Performance  Qualification  Test  (SPQT)  16.  SPQT  16  addressed  nine  test  cases.  The  test  cases 
are  listed  in  table  4. 1 . 12-1 . 

TABLE  4.1.12-1.  DT&E  SPQT  16  TEST  CASES 


Test  Case 

Description  ^ 

01 

Capacity  and  Delay  (Small  Sector  Peak  and  Range  Distribution  Peak  without  Mode  S) 

02 

Capacity  and  Delay  (Small  Sector  Peak  and  Range  Distribution  Peak  with  Mode  S) 

03 

Capacity  and  Delay  (Azimuth  Peak  without  Mode  S) 

04 

Capacity  and  Delay  (Azimuth  Peak  with  Mode  S) 

05 

Capacity  and  Delay  (Large  Sector  Peak  without  Mode  S) 

06 

Capacity  and  Delay  (Large  Sector  Peak  with  Mode  S) 

07 

Radar  Only  Report  Elimination  Under  Target  Overload  Conditions 

08 

CPU  Reconfiguration  with  Capacity 

09 

GRAM  Reconfiguration  with  Capacity 
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Capacity  scenarios  of  search,  beacon,  Mode  4,  and  FRUIT  were  injected  into  the  ARSR-4  along 
with  194  false  search  targets  per  scan  during  the  DT«feE  test.  The  ARSR-4  search  test  target 
generator  (STTG)  and  a  separate  beacon  test  target  generator  were  used  to  inject  the  test  targets. 
An  ARSR-4  test  set  simulated  the  Mode  S,  recorded  CD-2  reports,  and  compared  the  number  and 
position  of  the  reports  to  expected  values.  The  test  set  also  measured  the  processing  delay  of  each 
report  from  antenna  boresight  to  output  from  the  radar. 

During  OT&E,  a  subset  of  the  DT&E  SPQT  16  tests  were  repeated.  There  were  several 
differences  in  the  test  methods  between  the  SPQT  16  and  OT&E  tests.  First,  since  the  Mode  S 
was  not  available  at  Mt.  Laguna,  only  tests  with  an  ATCBI-5  configuration  were  performed 
during  OT&E.  Also,  the  capability  to  inject  Mode  4  test  targets  was  not  available  at  Mt.  Laguna. 
Finally,  unlike  the  SPQT  test,  the  OT&E  capacity  and  delay  tests  were  performed  with  the  ARSR- 
4  second  function  tracker  enabled,  since  this  was  the  operational  configuration  at  Mt.  Laguna. 

Figure  4. 1 . 12-1  shows  the  OT&E  test  configuration.  The  beacon  test  target  scenarios  were 
designed  using  a  PC-based,  Sensis  VideoBITS.  VideoBITS  produced  beacon  reply  video  which 
modulated  the  RF  generator  of  a  UPM-155  beacon  test  set.  The  resultant  RF  beacon  test  targets 
were  then  injected  into  the  ATCBI-5  through  a  test  port  at  the  front  of  the  receiver/transmitter 
unit.  After  ATCBI-5  downconversion,  the  quantized  video  output  was  then  fed  to  the  ARSR-4 
beacon  processor  along  with  the  mode  pair  triggers. 


FIGURE  4.1.12-1  .  CAPACITY  AND  DELAY  TEST  CONFIGURATION 
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The  ARSR-4  search  STTG  injected  both  RF  and  digital  test  targets  into  the  ARSR-4.  The  start 
and  stop  range,  start  and  stop  azimuth,  range  movement,  and  azimuth  movement  were  adjustable 
via  the  LDC/RMS. 

ARSR-4  CD-2  data  were  recorded  using  IRES  connected  to  the  user  one  ports  (AFl  and  AF2). 
Two  user  ports  fed  data  to  the  IRES  recorder  at  9600  bps  each.  To  measure  target  delay,  sector 
mark  messages,  generated  by  a  Sensis  Beacon  Extractor  and  Recorder  (BEXR)  were  input  to  the 
third  channel  of  IRES.  Sixty-four  sector  mark  messages  were  generated  in  each  scan  and  evenly 
distributed  throughout  the  scan.  All  recorded  messages  were  time  tagged  by  the  IRES  recorder 
and  saved  in  the  same  surveillance  file. 

The  ARSR-4  ARP  triggered  BEXR,  thus  giving  an  antenna  azimuth  reference  to  the  generated 
sector  marks.  The  ARP  also  fed  a  logic  analyzer  along  with  the  generated  sector  marks.  The  logic 
analyzer  measured  the  latency  between  the  ARP  and  sector  mark  zero  to  determine  the  BEXR 
delay  in  generating  the  sector  marks.  The  measured  BEXR  delay  was  then  subtracted  from  report 
delay  calculations  during  analysis. 

Data  was  recorded  with  a  computer  connected  to  the  ARSR-4  MPS  port.  The  data  included 
ARSR-4  alarms  and  any  reconfiguration  of  on-line  elements  during  the  test. 

The  ATCBI-5  transmitter  was  turned  off  for  the  tests.  The  OMNI  and  DIR  antenna  cables  were 
disconnected  to  prevent  reception  of  live  beacon  replies.  The  ARSR-4  and  ARSR-3  transmitters 
were  disabled  to  reduce  the  number  of  live  search  targets  received  by  the  radar. 

Table  4. 1 .12-2  describes  each  of  the  OT&E  capacity  and  delay  tests  performed.  The  OT&E  tests 
were  performed  with  the  13JUN95  software  build  in  the  system. 

TABLE  4.1. 12-2.  OT&E  CAPACITY  AND  DELAY  TESTS 


Run  t 

Description 

541 

790  search  and  800  beacon  test  targets  injected.  Search  targets  had  range  movement 

of  300  knots.  ARSR-3  transmitter  off. 

595 

60  search  and  12  beacon  targets  aligned  along  the  same  azimuth  radial. 

Run  541  was  performed  with  a  scan  capacity  of  790  search  and  800  beacon  targets  injected.  The 
search  test  targets  consisted  of  73  radials,  each  with  10  RF  targets  and  a  single  radial  with  60 
digital  test  targets  injected.  The  search  test  targets  were  given  range  movement  so  that  they  were 
tracked  and  output  from  the  second  function  tracker. 

The  800  beacon  test  targets  consisted  of  80  spokes  of  10  test  targets  each.  The  spoked  beacon 
test  targets  were  stationary.  There  was  no  FRUIT  injected  for  this  test. 

Run  595  tested  the  azimuthal  capacity  of  the  ARSR-4.  Sixty  digital  search  test  targets  and  12 
beacon  targets  were  injected.  There  was  no  FRUIT  injected  for  this  test. 


103 


Data  Analysis 

For  capacity  analysis,  report  counts  were  compared  to  the  expected  inputs  from  the  STTGs.  The 
IRES  COUNTPCS  and  SCANSUM  programs  produced  report  counts  per  scan.  The  PLOTSCAN 
program  produced  a  graphical  representation  of  report  counts  per  scan. 

The  FIXSECTR,  CMPDELAY,  and  DELAY  programs  in  IRES  were  used  in  delay  analysis. 
FIXSECTR  reformatted  the  sector  marks  (which  appear  as  ARSR-4  RTQC  messages)  into  IRES 
formatted  sector  marks.  CMPDELAY  computed  the  delay  of  each  report.  A  linear  interpolation 
using  report  azimuth  and  time  was  performed  on  all  surveillance  reports.  Consecutive  sector 
marks  were  used  for  true  azimuth  reference  in  the  calculation. 

The  DELAY  program  plotted  the  computed  delays  in  a  histogram  format  versus  time.  Counts  for 
the  different  report  types  were  displayed  using  different  colors.  DELAY  also  displayed  the 
maximum  delay  for  each  report  type. 

Results 

Run  541  contained  100  scans  of  data  with  790  search  and  800  beacon  test  targets  injected.  Figure 
4. 1.12-2  shows  a  graphic  representation  of  reports  per  scan.  The  upper  plot  in  the  figure  shows  the 
radar  only  report  counts  (upper  trace),  beacon  only  report  counts  (middle  trace),  and  radar-beacon 
merge  report  counts  (lower  trace)  per  scan.  The  data  shows  a  periodic  drop  in  the  search  and  beacon 
reports  per  scan  coincident  with  a  rise  in  the  number  of  merged  reports  per  scan.  Since  the  search 
targets  had  motion  and  the  beacon  targets  were  stationary  during  the  test,  the  merge  rate  was  low. 

The  lower  plot  in  figure  4. 1 .12-2  shows  the  status  message  and  beacon  RTQC  report  counts  per  scan. 
The  ARSR-4  output  a  beacon  RTQC  on  each  scan.  Note  that  while  the  ARSR-4  is  in  maintenance 
mode  to  support  search  test  target  injection,  search  RTQCs  are  not  output  from  the  ARSR-4  and  are 
not  seen  in  the  figure. 

The  number  of  status  messages  per  scan  fluctuated.  The  bits  in  the  CD-2  status  message  which 
changed  during  the  test  include  the  Beacon  RTQC  Alarm  (BRTQCA),  Beacon  Channel  On-line 
(BCOL),  Mode  4  Alarm  (M4ALA),  Weather  Channel  Status  (WXCHST),  and  Port  Status  alarms 
(P04STA,  P03STA).  Data  collected  at  the  MPS  monitor  showed  no  ARSR-4  alarm  activity  in  the 
beacon.  Mode  4,  weather  channel  or  user  1  IRES  ports  during  the  test.  There  were  no  indications  of 
channel  reconfigurations  during  the  test.  There  were  also  no  indications  of  buffer  overflow  or  overload 
conditions  for  user  1 .  Therefore,  the  toggled  bits  in  the  status  message  during  the  test  were  not 
consistent  with  status  reported  at  the  MPS.  The  toggled  bits  in  the  CD-2  status  message  were 
erroneous. 

Table  4. 1.12-3  lists  the  report  counts  for  RUN  541 .  The  ARSR-4  reported  740  beacon  reports  (BO 
plus  radar  reinforced  (RR))  on  each  scan.  A  military  map  (used  to  suppress  beacon  reflections  fi'om  the 
ARSR-3  tower)  was  enabled  during  the  test.  The  map  filtered  the  output  of  beacon  reports  from  330° 
to  0°.  Therefore,  the  expected  number  of  beacon  reports  per  scan  was  740  rather  than  the  800  injected 
targets.  The  ARSR-4  output  the  expected  number  of  beacon  reports  throughout  the  test. 
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TABLE  4. 1 , 12-3.  RUN  541  REPORTS  PER  SCAN 
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Table  4.1.12-3  shows  that  the  number  of  search  (RO  plus  RR)  reports  varied  each  scan  and  never 
equaled  the  expected  790  reports.  Further  investigation  into  the  apparent  loss  of  search  data  revealed 
that  there  was  an  uneven  movement  of  the  search  test  targets  into  and  out  of  the  coverage  area  during 
the  test.  Therefore,  the  STTG  did  not  consistently  inject  790  targets  per  scan. 

The  data  for  RUN  541  was  filtered  to  eliminate  the  effects  of  the  moving  targets  on  the  fluctuating 
search  report  counts.  Table  4. 1 .12-4  shows  the  number  of  missing  search  reports  per  scan  after  the 
movement  effects  were  removed.  The  table  only  includes  search  data  for  the  RF  test  targets,  (i.e.,  73 
radials  of  10  targets  each).  The  table  shows  that  the  number  of  missing  reports  never  exceeds  20  on  a 
single  scan.  It  can  also  be  seen  that  the  scans  on  which  the  number  of  missing  reports  exceeds  8  is 
nearly  periodic. 


TABLE  4. 1 . 12-4.  RUN  541  NUMBER  OF  MISSING  SEARCH  TARGETS  PER  SCAN 
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FIGURE  4.1.12-2  RUN  541  TARGET  COUNTS  VERSUS  SCANS 


FIGURE  4.1.12-3  RUN  541  ARSR-4  REPORT  DELAY  DISTRIBUTION 
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The  ranges  and  azimuths  of  the  search  reports  missing  from  the  recorded  file  were  manually  entered 
into  a  spreadsheet.  Figure  4. 1.12-4  shows  the  azimuth  distribution  of  the  missing  search  reports  for  the 
entire  data  tile.  Most  of  the  search  data  losses  in  the  area  around  63,  120,  and  262  degrees  can  be 
attributed  to  excessive  attenuation  by  the  geocensor  map.  These  missing  reports  indicate  a  detection 
problem  and  not  a  capacity  problem.  The  need  for  geocensoring  in  these  areas  is  further  discussed  in 
the  Surveillance  Coverage  and  Primary  False  Alarm  Rate  sections  of  this  report. 

At  greater  azimuths  (around  347°),  individual  radials  of  search  reports  were  periodically  lost 
throughout  the  data  file.  These  missing  search  reports  were  the  result  of  filtering  of  beacon  reports  by 
the  military  map  set  up  from  330°  to  U“.  L)ue  to  the  moving  search  test  targets  and  stationary  beacon 
test  targets,  the  two  types  of  targets  periodically  merged.  A  reinforced  (and,  therefore  a  search)  report 
was  not  output  from  the  system  in  this  region. 
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HGURii  4. 1  12-4.  RUN  541  AZIMUTH  DISTRIBUTION  OF  MISSING  SEARCH  REPORTS 

Under  the  capacity  load,  the  ARSR-4  lost  some  search  targets  but  consistently  output  the  expected 
number  of  beacon  reports  per  scan.  After  eliminating  the  efifects  of  the  military  map  on  the  missing 
search  reports,  the  number  of  missing  search  reports  dropped  below  1  percent  per  scan  with  most  of 
those  reports  in  areas  with  excessive  geocensoring  (a  detection  issue).  The  reporting  of  greater  than  99 
percent  of  the  search  targets  during  the  test  is  most  likely  operationally  acceptable. 

The  report  delay  was  measured  under  the  capacity  conditions  of  RUN  54 1 .  Azimuth  referenced, 
artificial  sector  marks  were  generated  by  BEXR  and  used  as  a  source  of  true  azimuth  during  the  test. 
The  delay  from  the  ARSR-4  ARP  to  the  BEXR  sector  mark  0  was  monitored  with  a  logic  analyzer. 
The  average  sector  mark  latency  (i.e.,  the  BEXR  delay)  during  RUN  541  was  54. 12  ms  and  never 
varied  by  more  than  10  ms  during  the  test.  This  value  is  roughly  two  orders  of  magnitude  less  than  the 
specified  1.5  second  maximum  delay,  showing  that  the  BEXR  delay  was  negligible  in  the  calculation. 

The  measured  report  delays  were  adjusted  to  account  for  the  measured  BEXR  sector  mark  delay,  the 
data  transmission  delay  to  the  IRES  recorder  (since  the  1 .5  second  requirement  is  to  the  input  of  the 
modems)  and  the  delay  'n  time  tagging  the  reports  in  IRES. 
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The  average  BEXR  sector  mark  delay  (54  ms)  was  used  in  the  delay  adjustment.  The  data  transmission 
delay  for  the  longest  message  in  the  CD-2  format  was  used.  At  9600  bps,  the  delay  for  the  beacon 
message  (seven  words  plus  one  idle  word)  is  10  ms.  Finally,  since  the  IRES  recorder  services  an 
interrupt  to  flush  its  buffers  every  7  ms,  this  number  was  subtracted  from  the  report  delay.  The  total 
delay  adjustment  used  in  analysis  was  37  ms  (i.e.,  54-10-7). 

Figure  4. 1 . 12-3  shows  the  report  delay  distribution  for  Run  541  in  a  histogram  format.  There  are  three 
different  report  delay  distributions  in  the  figure.  The  BO  distribution  has  the  highest  peak  (and  the  least 
delay).  The  RO  distribution  has  the  second  highest  peak  (and,  as  expected,  has  the  greatest  delay  due 
to  scan-to-scan  correlation).  The  radar-beacon  merged  RB  distribution  is  coincident  with  the  beacon 
only  distribution.  The  number  of  merged  reports  is  low  due  to  the  inability  to  consistently  align  the 
moving  search  test  targets  with  the  stationary  beacon  test  targets. 

The  right  hand  portion  of  the  figure  shows  the  minimum,  maximum,  and  mean  delays  for  each  report 
type.  The  data  shows  that  the  maximum  delays  for  each  report  type  were  within  the  1 .5-second 
requirement  except  the  RO,  where  the  maximum  report  delay  was  1 .55  seconds.  Further  investigation 
revealed  that  1 1  RO  reports  exceeded  the  1.5-second  delay  requirement  during  the  test.  All  of  the 
reports  that  exceeded  the  1.5-second  limit  were  located  on  the  25°  azimuth  radial. 

The  data  shows  that  the  vast  majority  of  reports  of  each  type  fall  within  the  1.5-second  delay  limit. 

Due  to  inherent  inaccuracies  in  the  measurement,  the  small  number  of  search  only  reports  exceeding 
the  limit  is  not  operationally  significant.  In  addition,  if  the  reinforcement  rate  had  been  higher  during  the 
test  (more  representative  of  real-world  conditions),  then  those  RO  reports  that  exceeded  the  1.5- 
second  delay  requirement  would  most  likely  have  been  reinforced  RB  reports  vvdth  a  smaller  delay. 

Run  595  was  performed  to  test  the  radial  capacity  of  the  ARSR-4.  A  strobe  of  60  digital  search  and  12 
beacon  targets  were  injected  into  the  ARSR-4  during  the  test.  The  search  targets  had  radial  movement 
of 562.5  knots.  The  beacon  targets  were  stationary.  Therefore,  the  merge  rate  varied  during  the  test. 

Table  4. 1. 12-5  shows  that  at  least  60  target  reports  were  output  on  most  of  the  scans.  Twelve  beacon 
reports  (RB  +  BO)  were  output  on  each  scan.  The  search  reports  (RO  +  RB)  per  scan  varied  between 
56  and  60  throughout  the  test.  On  those  scans  where  less  than  60  total  target  reports  were  output,  the 
STTG  injected  less  than  60  search  test  targets  due  to  uneven  target  movement  into  and  out  of  the 
coverage  area.  The  maximum  RO  report  delay  during  the  test  was  1 .22  seconds.  The  radial  capacity 
and  delay  was  operationally  acceptable. 
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TABLE  4. 1 . 12-5.  RUN  595  TARGET  COUNTS  PER  SCAN 
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Conclusions 

a.  DT&E  SPQT  16  tests  fully  exercised  the  capacity  and  delay  of  the  ARSR-4  with  and 
without  the  Mode  S  in  the  test  configuration.  The  SPQT  16  tests  of  large  sector  peak  and  small 
sector  peak  capacity,  and  Central  Processing  Unit  (CPU)  and  Global  Random  Access  Memory 
(GRAM)  reconfiguration  under  capacity  conditions  were  not  tested  during  OT&E.  In  addition, 
tests  with  the  Mode  S  were  not  performed  at  Mt.  Laguna. 

b.  The  ARSR-4  can  process  and  provide  message  outputs  for  a  steady  state  maximum  load  of 
800  aircraft  returns  within  the  primary  radar  coverage  area  in  the  ATCBI  configuration.  Most  of 
the  small  number  (less  than  1  percent)  of  search  targets  not  available  in  the  output  data  file  were 
caused  by  geocensor  map  attenuation.  No  beacon  reports  were  dropped. 

c.  The  maximum  report  delay  under  scan  capacity  conditions  is  acceptable.  The  small  number 
of  search  only  reports  (11)  whose  delays  exceeded  the  1.5-second  requirement  are  statistically 
insignificant. 

d.  The  ARSR-4  can  adequately  process  and  provide  message  outputs  for  an  azimuth  peak  of 
60  aircraft  returns  aligned  in  an  azimuth  radial. 

Recommendations 

Search,  beacon  and  weather  capacity,  and  delay  tests  should  be  repeated  for  those  interfaces  not 
tested  during  OT&E  (Mode  S,  EARTS,  and  MicroEARTS).  Those  tests  should  include  more 
stringent  FRUIT  scenarios  to  test  the  ARSR-4  beacon  target  processor  capacity. 

4.1.13  Weather  End-to-End  Performance. 

Purpose 

Verify  that  the  ARSR-4  weather  data  is  accurate  and  timely. 

Test  Objectives 

a.  Verify  that  the  ARSR-4  can  detect  five  levels  of  weather  information  corresponding  to  the 
standard  NWS  levels  2  through  6. 

b.  Verify  that  the  ARSR-4  can  output  three  levels  of  weather  to  the  ARTCC  computers  in 
the  proper  format. 

c.  Verify  that  the  ARSR-4  weather  processor  does  not  output  false  weather  due  to  returns 
from  ground  clutter  during  anomalous  propagation  conditions. 

Test  Description 

Limited  tests  of  the  ARSR-4  weather  detection  and  reporting  functions  were  performed  with  real 
weather  at  Mt.  Laguna  because  weather  was  rarely  available  in  the  San  Diego  area.  When  weather 
was  present,  personnel  at  the  center  requested  that  the  ARSR-4  transmitter  be  turned  off  because 
of  interference  to  the  ARSR-3  weather  processor. 
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The  DT&E  General  Site  Verification  (GSV)  procedure  was  repeated  during  the  OT&E  regression 
period.  The  procedure  includes  sections  on  five-level  weather  processing,  three-level  weather 
level  processing,  weather  processing  in  clutter,  and  weather  averaging  and  thresholding.  All  of 
these  tests  were  performed  using  ARSR-4  weather  test  targets. 

In  addition  information  was  collected  through  controller  questionnaires.  ATC  observed  the 
display  during  various  environmental  conditions  including  weather,  anomalous  propagation 
conditions,  and  bird  activity. 

Results 

Results  of  the  GSV  test  indicated  that  the  expected  weather  levels  and  positions  were  displayed 
on  the  LDC  when  the  test  targets  were  injected. 

During  the  initial  phase  of  OT&E,  a  weather  reporting  problem  was  identified  in  the  ARSR- 
‘4/HOST  interface.  The  ARSR-4  output  three  levels  of  weather  in  the  CD  data  to  the  ARTCC  but 
the  HOST  computers  could  only  handle  two  levels  of  weather.  A  HOST  software  patch 
configured  the  ARSR-4  medium  and  high  level  weather  as  high  and  the  ARSR-4  low  level 
weather  as  low. 

Controller  evaluation  of  the  system  during  OT&E  retest  revealed  that  the  weather  information 
from  the  HOST  was  different  than  the  DARC  weather  information  because  the  three  level  to  two 
level  weather  modification  had  not  yet  been  implemented  in  DARC. 

In  addition  to  weather  reporting  problems  identified,  controllers  identified  times  where  false 
weather  was  being  presented  on  their  displays.  The  source  of  the  false  weather  was  anomalous 
propagation  in  the  Mt.  Laguna  area. 

Conclusions 

a.  The  ARSR-4  weather  detection  and  reporting  capability  was  not  fully  evaluated  at  Mt. 
Laguna. 

b.  Limited  tests  using  test  targets  show  that  the  ARSR-4  weather  processor  can  process  and 
display  three  or  five  levels  of  weather  on  the  LDC  at  the  correct  position. 

c.  The  DARC  system  displays  ARSR-4  weather  information  differently  than  the  HOST  does 
due  to  the  absence  of  a  software  patch  to  convert  ARSR-4  three  level  weather  to  two  level 
weather.  This  may  cause  confusion  if  the  backup  system  is  switched  on  during  times  of  weather. 
The  inconsistent  weather  processing  between  ARTCC  computers  is  not  suitable  for  ATC. 

Recommendations 

a.  Further  weather  tests  should  be  conducted  at  another  ARSR-4  site  where  weather  is  more 
prevalent.  ARSR-4  weather  products  should  be  compared  to  weather  products  from  NWS  radars 
to  verify  accurate  weather  reporting. 
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b.  DARC  weather  processing  should  be  corrected  to  coincide  with  the  weather  processing  in 
NAS  so  that  consistent  weather  information  is  reported  to  the  controller  when  the  backup  system 
is  switched  on-line. 

4. 1  ■  14  System  Control  Operation. 

The  tests  in  this  section  measured  the  ARSR-4  functional  and  physical  interface  with  the  RMS. 
The  ability  of  the  ARSR-4  RMS  to  reliably  provide  the  means  to  control  and  maintain  the  radar 
and  monitor  its  performance  was  tested. 

This  section  is  divided  into  the  seven  subsections  listed  below,  each  describing  a  different  facet  of 
RMS  tests. 


4.1.14.1 

RMS  Terminal  Operation 

4.1.14.2 

System  Control  and  Configuration 

4.1.14.3 

Equipment  Performance 

4.1.14.4 

Alarm  Reporting  Functions  and  Fault  Isolation 

4.1.14.5 

Adjustable  Parameters 

4.1.14.6 

Data  Extraction 

4.1.14.7 

Disk  Functions 

Section  4.1.14.1  describes  the  tests  of  the  RMS  interface  to  the  different  system  terminals. 
Sections  4. 1 . 14.2  through  4. 1 . 14.7  each  describe  a  test  of  functions  performed  by  one  of  the 
ARSR-4  RMS  menus.  Figure  4.1.14-1  shows  the  ARSR-4  RMS  main  menu. 


ARSR-4 

REMOTE  MONITORING  SYSTEM  FUNCTIONS 

1. 

CONTROL/CONFIGURATION 

9.  QUICK  LOOK 

2. 

PERFORMANCE 

10.  LOG  OFF 

3. 

ALARM  REPORTS 

11.  BACKUP  NON-VOLATILE 

SAP/FAPS  TO  PROM 

4. 

FAULT  ISOLATION  TESTING 

12.  BACKUP  SAFE  DATA  TO 

PROM 

5. 

PARAMETERS 

6. 

DATA  EXTRACTION 

7. 

DISK  FUNCTIONS 

8. 

MAIL 

FIGURE  4.1.14-1.  ARSR-4  MAIN  RMS  MENU 
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4.1.14.1 


RMS  Terminal  Operation. 


Purpose 

Ensure  that  all  RMS  functions  can  be  accessed  at  each  local  terminal  location  (LDC/RMS, 
Maintenance  Display  Terminal  (MDT),  and  the  Transmitter  Maintenance  Display  Terminal 
(TMDT)). 

Test  Objectives 

a.  Verify  that  all  RMS  capabilities  are  available  at  the  LDC,  MDT,  and  TMDT  locations. 

b.  Verify  that  ARSR-4  system  control  can  be  transferred  to  each  terminal  without  conflicts. 

c.  Verify  that  system  control  is  automatically  transferred  to  the  MPS  upon  failure  of  the 
terminal  with  system  control. 

Test  Description 

The  ARSR-4  was  monitored  and  controlled  from  each  terminal  location  to  verify  that  all  RMS 
functions  could  be  accessed.  Since,  by  design,  only  one  terminal  should  have  system  control  at  a 
time,  control  was  transferred  between  terminals  to  verify  a  smooth  transfer.  In  addition,  the 
terminal  which  had  system  control,  was  faulted  to  verify  that  control  is  automatically  transferred 
to  MPS. 

Data  Analysis 

System  control  indications  were  monitored  on  the  RMS  menus  to  verify  that  the  expected 
terminal  locations  had  system  control.  RMS  menu  information  presented  at  each  terminal  was 
compared. 

Results 

Each  terminal  can  access  ARSR-4  software  configuration  information.  Figure  4.1.14.1-1  shows 
the  ARSR-4  configuration  information  available  via  the  RMS.  For  each  software  segment,  the 
current  software  version  number  and  checksum  are  available  to  the  user.  In  addition,  access  from 
any  terminal  location  is  password  protected. 
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- 

ARSR-4 

REMOTE  MONITORING 

SYSTEM 

- -f 

T 

FIXED  SEGMENTS 

CUR 

VER 

CHK 

SUM 

SYSTEM  SEGMENT 

CUR 

VER 

CHK 

SUM 

SYSTEM  SEGMENT 

OPERATION  CODE 

BIT  BCN  TRAN  TBL 

PTRS 

SCREENS /MENUS 

BIT  BCN  TKAN  TBL 

DATA 

FORMATTER  DEFINITIONS 

BIT  SRCH  TRAN  TBL 

PTRS 

NON-VOLATILE  SAP/FAPS 

BIT  SRCH  TRAN  TBL 

DATA 

VOLATILE  SAP/FAPS 

FIT  TABLES 

CONFIGURATION 

RPLAU 

SAFE  DATA 

ARADES  MP  CURVES 

ENTER  PASSWORD  TO 

LOGIN: 

FIGURE  4.1.14.1-1.  ARSR-4  SOFTWARE  VERSION/CHECKSUM  MENU 


Operational  parameters  are  provided  for  each  functional  area  of  the  system.  This  includes:  search, 
beacon,  merge,  mode  4,  weather,  antenna,  map,  user,  and  general  setup  parameters. 

System  performance  can  be  monitored  from  each  terminal  location.  Beacon,  search,  and  mode  4 
processor  performance  statistics  are  monitored  on  a  scan-to-scan  basis.  Transmitter  and  receiver 
performance  are  monitored  with  readbacks  from  critical  areas  within  those  units.  Counts  of 
messages  sent  to  each  user  are  available  at  each  terminal. 

ARSR-4  alarm  information  is  sent  to  each  terminal  location  via  the  RMS  and  the  functionality 
exists  to  run  fault  isolation  tests  from  each  terminal. 


Performance  parameters  are  accessible  at  each  terminal  location.  Some  parameters  are  accessible 
only  when  the  terminal  has  system  control.  This  is  acceptable  since  the  terminal  with  system 
control  should  be  the  only  terminal  with  access  to  these  parameters. 

During  the  first  phase  of  OT«&E,  the  MDT  was  powered  off  and  disconnected  from  the  RCJB 
while  the  MDT  had  system  control.  This  simulated  an  MDT  failure.  After  reconnection  and  MDT 
power  up,  the  MDT  was  locked  out  while  LDC/RMS  indicated  that  the  MDT  was  in  control.  A 
cold  start  was  necessary  to  force  system  control  to  MPS. 

Subsequent  retests  with  the  6SEP94  and  25MAY95  software  builds  in  the  system  could  not 
reproduce  the  problem.  The  system  responded  as  expected  with  system  control  immediately  going 
to  the  MPS  as  the  MDT  was  faulted.  In  each  case,  the  MDT  gave  up  control  in  less  than  40 
seconds. 

Throughout  OT&E,  the  reliability  of  the  LDC,  and  in  particular.  Video  Display  Terminal  (VDT) 
in  the  LDC  was  poor.  The  LDC  reliability  is  further  discussed  in  section  4.2.2. 
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Conclusions 


Terminals  connected  to  the  LDC,  MDT,  and  TMDT  ports  operate  in  a  similar  manner  when 
monitoring  or  controlling  the  system.  General  terminal  operation  and  function  at  the  LDC 
location  (not  considering  its  reliability)  is  acceptable. 

Full  control  of  the  ARSR-4  can  be  performed  at  any  terminal  location  at  the  local  site. 
Transmitter  operation,  antenna  drive  control,  software  initialization,  and  modes  of  operation  are 
accessible  at  each  terminal  location. 

Performance  parameters  are  adequate  to  provide  the  operator  with  the  data  necessary  to  verify 
system  health. 

Since  the  same  RMS  information  is  available  at  each  terminal  location,  the  MDT  can  be  used  as  a 
backup  for  the  unreliable  LDC  terminal. 

4. 1 . 14.2  System  Control  and  Configuration  fRMS  Menu  1) 

Purpose 

Ensure  that  the  RMS  provides  the  necessary  hardware,  software,  and  control  signals  to  adjust  the 
operational  equipment  and  properly  configure  parameters  to  the  needs  of  an  unique  site. 

Test  Objectives 

a.  Verify  proper  operation  of  the  RMS  control  and  status  functions  which  include:  selection 
of  system  control  location,  transmitter  control,  antenna  control,  selection  of  ARSR-4  operating 
mode,  and  system  reset. 

b.  Verify  proper  operation  of  the  RMS  system  hardware  configuration  functions  which 
provide  status  and  control  of  reconfigurable  elements  (such  as  beacon  channel  or  synchronizers). 

c.  Verify  that  the  Interpulse  Period  (EP)  is  selectable  at  the  RMS  individually  for  each  sector. 

d.  Verify  that  the  frequency  mode  is  selectable  at  the  RMS  individually  for  each  sector. 

e.  Verify  that  the  polarization  is  selectable  at  the  RMS  individually  for  each  sector. 

f.  Verify  that  the  RMS  correctly  reports  the  status  of  each  terminal  as  well  as  the  status  of 
the  Mode  S  interface. 

g.  Verify  that  the  RMS  provides  transmitter  calibration  control  and  status. 
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Test  Description 

Functions  were  exercised  on  ARSR-4  RMS  menu  1,  “System  Control  and  Configuration”  and  its 
submenus.  The  system  was  monitored  to  ensure  that  the  exercised  commands  operated  as 
expected. 

Figure  4.1.14.2-1  shows  ARSR-4  RMS  menu  1.  The  menu  is  divided  into  submenus  which 
provide  the  means  to  control  on-line  reconfigurable  elements  and  system  operating  modes. 


1  SYSTEM  CONTROL  AND  CONFIGURATION 

1.  CONTROL  AND  STATUS 

2.  SYSTEM  HARDWARE  CONFIGURATION 

3.  SECTOR  CONTROL  -  IP  MODE 

4.  SECTOR  CONTROL  -  FREQUENCY  MODE 

5.  SECTOR  CONTROL  -  POLARIZATION 

6.  SITE  CONFIGURATION 

7.  TRANSMITTER  RF  PORT  CALIBRATION  VERIFICATION 

8.  TRANSMITTER  RF  DETECTOR  INPUT  POWER 


FIGURE  4.1.14.2-1.  RMS  MENU  1  “CONTROL  AND  CONFIGURATION” 


Results 

Figure  4.1.14.2-2  shows  menu  1.1,  “System  Status  and  Control.”  System  control  was 
successfully  transferred  between  terminals.  Control  automatically  returns  to  MPS  when  control  is 
released  at  a  terminal.  Transmitter  and  antenna  controls  operated  normally.  The  system  mode 
controls  operated  correctly.  Warm  and  cold  starts  were  successfully  initiated  from  the  RMS.  The 
transmitter  power  override  function  was  not  tested  at  Mt.  Laguna. 
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1.1  SYSTEM  CONTROL  AND  STATUS 

CURRENT  STATUS  » 


CONTROL  POINT: 

(LDC, 

MPS, 

MDT,  TMDT) 

ANTENNA  DRIVE  1: 

(ON/OFF) 

ANTENNA  DRIVE  2: 

(ON/OFF) 

SYSTEM  MODE: 

(OPER,  REPR,  MANT) 

TRANSMITTER: 

(ON/OFF) 

AUTO 

TX: 

(ON/OFF) 

CONTROL  COMMANDS 

» 

101. 

TAKE  CONTROL 

107. 

TRANSMITTER 

ON 

203. 

SYSTEM 

TO 

MANT  MODE 

102. 

RELEASE  CONTROL 

108. 

TRANSMITTER 

OFF 

204. 

SYSTEM 

TO 

REPR  MODE 

109. 

TRANSMITTER 

POWER 

205. 

SYSTEM 

TO 

OPER  MODE 

103. 

ANT  DRIVE  1 

ON 

OVERRIDE 

104. 

ANT  DRIVE  1 

OFF 

105. 

ANT  DRIVE  2 

ON 

201. 

WARM  START  , 

SYSTEM 

206. 

ENABLE 

AUTO  TX 

106. 

ANT  DRIVE  2 

OFF 

202. 

COLD  START  , 

SYSTEM 

207. 

DISABLE  AUTO  TX 

FIGURE  4.1.14.2-2.  RMS  MENU  1.1  “SYSTEM  CONTROL  AND  STATUS” 


On  menu  1.2,  “System  Hardware  Configuration,”  the  status  and  control  of  hardware  elements 
operated  as  expected.  The  RMS  provided  the  capability  to  reconfigure  hardware  elements  to 
On-line,  Standby,  Repair,  or  Lock  status. 

On  menu  1.3,  “Sector  Control  -  IP  Mode,”  selection  and  status  of  Second  Time  around  Clutter 
(STAC)  and  VIP  modes  operated  correctly.  Pulse  Agile  (PULS)  was  verified  during  DT&E  and 
observed  to  work.  However,  tests  were  not  repeated  during  OT&E  due  to  a  limited  number  of 
transmit  frequency  pairs  available  at  Mt.  Laguna. 

On  menu  1.5,  “Sector  Control  -  Polarization,”  linear  or  circular  polarization  was  successfully 
selected  for  individual  sectors. 

On  menu  1.6,  “Site  Configuration,”  mode  4  parameters  operated  as  expected.  LDC,  MDT,  and 
TMDT  terminal  status  was  correctly  reported  at  this  menu.  Mode  S  status  was  correctly  reported 
on  this  menu,  however,  channel  configuration  status  was  not  verified  due  to  the  absence  of  the 
Mode  S  at  Mt.  Laguna. 

On  menus  1.7  and  1.8,  transmitter  RF  port  calibration  verification  did  not  respond  correctly. 
Retest  with  the  25MAY95  software  build  produced  two  issues.  First,  the  calibrate  function  at 
menu  1.7  sometimes  turns  the  transmitter  RF  off  when  the  command  is  executed.  Second,  power 
readings  at  menus  2.1.1  and  2. 14  for  lookdown  sectors  did  not  clear  to  zero  after  the  lookdown 
channel  was  disabled. 
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Conclusions 

Functions  on  RMS  menus  1.1  through  1.6  operated  correctly,  providing  the  ability  to  effectively 
configure  and  control  the  ARSR-4. 

Transmitter  functions  on  menus  1.7  and  1.8  did  not  operate  correctly.  The  calibrate  function 
should  not  turn  the  transmitter  RF  off.  Power  readings  at  menus  2.1.1  and  2. 14  should  be 
consistent  with  the  actual  status  of  the  ARSR-4  transmitter. 

Recommendations 

The  identified  malfunctions  on  RMS  menus  1.7  and  1.8  should  be  corrected. 

4.1.14.3  Equipment  Performance  (RM S  Menu  2) 

Purpose 

Ensure  that  the  RMS  monitors  ARSR-4  performance  and  accurately  reports  data  to  the  user. 

Test  Objective 

Verify  that  the  RMS  reports  accurate  performance  information  via  menu  2,  “Equipment 
Performance”  to  ensure  the  system  is  operating  within  certified  limits. 

Test  Description 

Functions  were  exercised  on  ARSR-4  RMS  menu  2,  “Equipment  Performance”  and  its  submenus. 
The  system  was  monitored  to  ensure  that  the  exercised  commands  operated  as  expected  and  that 
accurate  information  was  presented  to  the  user. 

Figure  4.1.14.3-1  shows  RMS  menu  2.  The  menu  is  divided  into  categories  which  provide 
performance  data  for  the  transmitter  and  receiver  as  well  as  scan  statistics  and  test  target 
generation. 


2  EQUIPMENT  PERFORMANCE 


1.  TRANSMITTER 

2.  RECEIVER 

3.  CLUTTER  CAl'ICELLATION 

4.  SCAN  STATISTICS 

5.  DATA  COUNT  MONITOR 

6.  SPECTRUM  ANALYSIS 

7.  CALIBRATION  SERVO  CONTROL 

8.  SEARCH  TEST  TARGET  GENERATION 

9.  BEACON  TEST  TARGET  GENERATION 

10.  DISCRETE  VIDEOS 

11.  A-SCOPE  VIDEO 


12.  ATCBI  PERFORMANCE 

13.  HEIGHT  CALIBRATION  PERFORMANCE 

14.  CERTIFICATION 


FIGURE  4. 1 . 14.3-1 .  RMS  MENU  2  “EQUIPMENT  PERFORMANCE” 
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Data  Analysis 

RMS  performance  data  was  compared  with  the  actual  state  of  the  ARSR-4  or  with  recorded  data 
to  verify  the  correctness  of  the  data. 

Results 

On  Menu  2.1,  “Transmitter  Performance,”  transmitter  output  power.  Voltage  Standing  Wave 
Ratio  (VSWR),  and  collector  power  supply  bus  voltage  data  was  accurately  reported  for  the 
Lookdown,  A,  and  B  channels.  Beam  Steering  statistics  and  control  were  adequate. 

On  Menu  2.2,  “Receiver  performance”  Low  Noise  Amplifier  (LNA)  gain  and  phase  and  Minimum 
Discernible  Signal  (MDS)  values  are  provided  for  each  beam  and  frequency. 

Menu  2.3,  “Clutter  Cancellation,”  provides  Moving  Target  Indicator  (MTI)  Improvement  Factor 
and  Subclutter  Visibility  information  for  a  selected  area  of  clutter. 

On  Menu  2.4,  “Scan  statistics,”  accurate  statistics  for  each  major  functional  unit  are  provided. 
Areas  monitored  include:  Search  Target  Extractor  Inputs/Outputs,  First  and  Second  Function 
Scan-to-Scan  Correlator,  Beacon  Target  Detector,  Radar/Beacon  Reinforcement,  and  Editor  and 
Formatter  statistics. 

On  Menu  2.5,  “Data  Count  Monitor,”  numbers  are  accurately  compiled  over  a  user  selectable 
data  count  interval. 

On  menu  2.6,  “Spectrum  Analysis,”  was  successfully  performed  on  a  target  of  opportunity. 

On  menu  2.7,  “Calibration  Servo  Control,”  automatic  adjustments  to  the  ARSR-4  perform 
normally. 

On  menu  2.8,  “Search  Test  Target  Generation,”  all  test  target  scenarios  operated  correctly 
(including  the  Continuous  Wave  (CW)  test  parameters). 

On  Menu  2.9,  “Beacon  Operational  Test  Targets,”  functions  operated  properly.  At  menu  2.9.2, 
however,  test  targets  were  not  visible  on  the  LDC  for  any  test  target  scenario. 

Menu  2. 10,  2. 1 1,  and  2. 13  functions  were  not  tested  during  local  RMS  interface  testing. 

On  Menu  2.12,  “ATCBI  Performance,”  the  beacon  status  and  performance  information  was 
accurate. 

On  Menu  2.14,  “Certification,”  loss  of  redundancy,  RTQC,  alarms,  transmitter  power  and  VSWR, 
and  receiver  MDS  data  are  accurately  presented.  Figures  4. 1 . 14.3-2  and  4. 1 . 14.3-3  show  the 
certification  menus.  These  menus  were  used  to  certify  the  ARSR-4  for  ATC  after  OT&E  was 
completed. 
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2.14  CERTIFICATION 


PAGE  1  OF  2 


CURRENT  DATE  AND  TIME: 

CRITICAL  ALARMS  PRESENT: 
LOSS  OF  REDUNDANCY: 


(0  =  NO,  1  =  YES) 
(0  =  NO,  1  =  YES) 


BEACON  RTQC 

RANGE: 

NMI 

SEARCH  RTQC  RANGE: 

NMI 

BEACON  RTQC 

CENTER 

lACPS 

SEARCH  RTQC  CENTER: 

iACPs 

BEACON  RTQC 

AZIMUTH 

ACPS 

SEARCH  RTQC  AZIMUTH: 

ACPs 

BEACON  RTQC 

ALARM  _ 

AVE  XMITTER 

PWR  CH  A: 

dBw 

60 

uSEC  IMPROVEMENT  FACTOR: 

dB 

AVE  XMITTER 

PWR  CH  B: 

dBw 

90 

uSEC  IMPROVEMENT  FACTOR: 

dB 

AVE  XMITTER  PWR  LOOKDOWN : 

60  uS  VSWR  CH  A: 

60  uS  VSWR  CH  B: 

60  uS  VSWR  CH  LOOKDOWN: 


dBw 


90  uS  VSWR  CH  A: 

90  uS  VSWR  CH  B: 

90  uS  VSWR  CH  LOOKDOWN: 


FIGURE  4.1.1 4.3-2.  CERTIFICATION  MENU  -  PAGE  1 


2.14 

CERTIFICATION 

PAGE  2  OF  2 

CURRENT  DATE  AND  TIME:  _ 

BEAM 

ROW  MDS  FI 
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MDS  F2  LP 
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18 

dB 

dB 

9 

21 
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dB 

FIGURE  4.1.14.3-3.  CERTIFICATION  MENU  -  PAGE  2 


Conclusions 

a.  ARSR-4  performance  monitoring  accurately  reflected  the  health  of  the  transmitter  and 
receiver. 

b.  “Scan  Statistics”  and  “Data  Count”  menus  provided  accurate  ARSR-4  performance 
information. 

c.  The  “Certification”  menu  provided  sufficient  information  to  certify  the  use  of  the  ARSR-4 
in  NAS. 
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4. 1  ■  14.4  Alarm  Reporting  Functions  (RMS  Menu  S')  and  Fault  Isolation  fRMS  Menu  4) 


Purpose 

Ensure  that  ARSR-4  BIT  reports  any  radar  malfunction  promptly  and  that  FIT  provides  sufficient 
information  to  the  maintenance  technician  to  locate  and  replace  the  faulted  equipment. 

Test  Objectives 

a.  Verify  that  the  ARSR-4  detects  injected  faults  and  accurately  reports  the  alarm  status  on 
RMS  menu  3,  “Alarm  Reports.” 

b.  Verify  that  FIT  correctly  isolates  at  least  99.9  percent  of  all  detected  failure  faults  to  a 
group  of  no  greater  than  eight  Logical  Replaceable  Units  (LRUs). 

c.  Verify  that  BIT  reports  the  results  of  fault  isolation  to  the  RMS  after  completion  of  the 
automatic  diagnostic  process. 

Test  Description 

Tests  of  ARSR-4  BIT  and  FIT  operation  were  performed  at  the  same  time.  Faults  were  injected 
into  the  ARSR-4  to  verify  menu  3  and  menu  4  functions.  The  system  was  monitored  to  ensure 
that  the  expected  alarms  were  reported  by  BIT.  FIT  was  then  exercised  on  the  faulted  subsystem 
to  verify  that  the  correct  LRU  was  isolated.  Figure  4. 1 . 14.4-1  shows  RMS  menu  3.  BIT  is 
provided  for  all  major  subassemblies  and  most  LRUs.  When  an  alarm  appears  on  this  menu, 
further  investigation  is  done  by  traversing  downward  through  the  RMS  BIT  submenus. 


3  ALARM 

REPORTS 

1. 

PEPESTAL/RADOME 

8. 

DET 

CHAN 

1 

9. 

DET 

CHAN 

2 

2. 

TRANSMITTER 

10. 

DET 

CHAN 

3 

11. 

DET 

CHAN 

4 

3. 

ANT/RF/IF  RECEIVERS 

12. 

DET 

CHAN 

5 

13. 

DET 

CHAN 

6 

4. 

FREQ  GEN 

14. 

DET 

CHAN 

7 

5. 

SIGNAL  PROC  MISC. 

15. 

DATA  PROCESSOR 

16. 

WEATHER  STATION 

6. 

SYNC/MAP  A 

17. 

BEACON/MODE  4  A 

7. 

SYNC/MAP  B 

18. 

BEACON/MODE  4  B 

19. 

SOFTWARE  PERFORMANCE 

FIGURE  4.1.14,4-1.  RMS  MENU  3  -  ALARM  REPORTS 


Figure  4.1.14.4-2  shows  RMS  menu  4.  The  menu  is  very  similar  in  appearance  to  menu  3.  By 
design,  after  an  alarm  is  indicated  on  menu  3,  further  diagnostic  tests  for  the  alarmed  subsystem 
can  be  commanded  on  menu  4. 
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4  FAULT  ISOLATION 

TESTS 

1. 

PEDESTAL/RADOME 

7. 

DET  CHAN  1 

8. 

DET  CHAN  2 

2. 

TRANSMITTER 

9. 

DET  CHAN  3 

10. 

DET  CHAN  4 

3. 

ANT/RF/IF  RECEIVERS 

11. 

DET  CHAN  5 

12. 

DET  CHAN  6 

4. 

FREQ  GEN 

13. 

DET  CHAN  7 

5. 

SYNC/MAP  A 

14. 

DATA  PROCESSOR 

6. 

SYNC /MAP  B 

15. 

WEATHER  STATION 

16. 

BEACON/MODE  4  A 

17. 

BEACON/MODE  4  B 

FIGURE  4. 1 . 14.4-2.  RMS  MENU  4  -  FAULT  ISOLATION  TESTS 


The  function  of  every  alarm  was  not  exercised  during  OT&E.  It  was  impossible  to  produce  all 
fault  combinations  to  test  all  BIT  functions.  Alarm  threshold  values  were  adjusted  to  induce  hard 
and  soft  alarms.  In  addition,  a  subset  of  alarms  in  each  major  unit  was  tested  by  faulting  an  LRU 
and  observing  menu  3  for  an  alarm  indication. 

Hardware  faults  were  usually  introduced  by  removing  a  board  from  the  system,  disconnecting 
cables,  or  faulting  individual  chips  on  a  board. 


Data  Analysis 

After  each  fault  was  injected  into  the  ARSR-4,  RMS  menu  3  was  monitored  to  verify  that  the 
correct  hard  or  soft  alarm  indication  was  displayed.  Also,  alarm  status  (as  indicated  by  cabinet 
lights)  was  compared  to  the  alarm  status  presented  on  the  RMS  menus.  FIT  results  were 
compared  to  expected  results. 

Results 

On  menu  3.1,  “Pedestal/Radome,”  thresholds  were  changed  to  induce  soft  and  hard  alarms  for  the 
Azimuth  Pulse  Generator  (APG)  and  Pedestal  Enclosure  power  supplies  and  Motor  A  and  B 
Current.  In  each  case,  BIT  reported  the  correct  alarm  and  FIT  isolated  the  correct  LRU. 

Table  4. 1 . 14.4-1  shows  the  results  of  performing  BIT/FIT  when  faults  were  injected  in  the 
Pedestal/Radome.  In  each  case,  BIT  and  FIT  correctly  identified  and  isolated  the  injected  fault. 

TABLE  4.1.14.4-1.  “PEDESTAL/RADOME”  BIT/FIT  TEST  RESULTS 


No. 

Unit/LRU  faulted 

Fault  Method 

Result 

FIT 

Result 

1 

Interlock 

Enabled  '‘Rotation  Interlock  Bypass 
Switch” 

Passed 

Passed 

Oil  Level  Sensor 

Removed  Sensor 

Passed 

Passed 

Servo  Amplifier 

Removed  cable  at  13A2A4J2 

Passed 

Passed 

Pedestal  Control  Cab 

Placed  local/remote  switch  to  local 

Passed 

Passed 
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On  menu  3.2,  “Transmitter,”  thresholds  were  adjusted  to  induce  power  supply,  VSWR,  average 
and  peak  power,  and  transistor  count  alarms  in  the  transmitter.  In  each  case,  BIT  returned  the 
correct  soft  or  hard  alarm  indication  and  FIT  isolated  the  correct  LRU. 

Table  4. 1.14.4-2  shows  the  results  of  performing  BIT/FIT  when  faults  were  injected  in  the 
Transmitter.  In  each  case,  BIT  and  FIT  correctly  identified  and  isolated  the  injected  fault.  The 
fault  injection  methods  shown  in  the  table  were  recommended  by  WEC. 

TABLE  4. 1. 14.4-2.  “TRANSMITTER”  BIT/FIT  TEST  RESULTS 


■  Test 
No. 

Unit/LRU 

faulted 

Fault  Metliod 

BIT 

Result 

FIT 

Result 

1 

Preamp  Switch 

Removed  J32  near  preamp  3 

Passed 

Passed 

2 

Pulse  Shape  Sequencer 

Pulled  pin  3  high  on  U76 

Passed 

Passed 

Grounded  TP68 

Passed 

Passed 

Grounded  pin  9  on  U69 

Passed 

Passed 

Removed  U56 

Passed 

Passed 

3 

RMS  Interface 

Removed  board 

Passed 

Passed 

4 

Loop  Controller 

Grounded  TP54 

Passed 

Passed 

Removed  Z7 

Passed 

Passed 

On  menu  3.3,  “Ant/RF/Intermediate  Frequency  (IF)  Receivers,”  thresholds  were  adjusted  to 
induce  ANT/RF/IF  power  supply  and  LNA  Gain  and  Phase  alarms.  In  each  case,  BIT  returned  the 
correct  soft  or  hard  alarm  indication  and  FIT  isolated  the  correct  LRU.  Table  4. 1 . 14.4-3  shows 
that  BIT  and  FIT  worked  properly  for  the  cabinet  blowers  and  Receiver  Interface  board. 

TABLE  4. 1 .14.4-3 .  “ANT/RF/IF  RECEIVERS”  BIT/FIT  TEST  RESULTS 


Test  ... 

Unit/LRU 

Fault  Method 

BIT 

FIT 

No. 

faulted 

Result 

Result 

1 

Cabinet  Blowers 

Turned  off  IF  receiver  cabinet  blowers 

Passed 

Passed 

2 

Receiver  Interface 

Removed  board 

Passed 

Passed 

On  menu  3.4,  “Freq  Gen,”  thresholds  were  adjusted  to  induce  RF  test  target  level  alarms.  BIT 
reported  the  correct  results  and  FIT  isolated  the  correct  LRUs. 


Table  4. 1 . 14.4-4  shows  that  BIT/FIT  worked  effectively  in  identifying  and  isolating  faults  in  the 
Frequency  Generator. 
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TABLE  4. 1 . 14.4-4.  “FREQ  GEN”  BIT/FIT  TEST  RESULTS 


Test 

Unit/LRU 

Fault  Method 

BIT 

FIT 

faulted 

Result 

Result 

1 

Oscillator 

Removed  cable  at  J2 

Passed 

Passed 

2 

Stale  Generator 

Removed  cable  at  J6 

Passed 

Passed 

3 

COHO  Generator 

Shorted  two  pins  on  U1 14 

Passed 

Passed 

4 

Transmit  Generator 

Removed  cable  at  J2 

Passed 

Passed 

5 

Waveform  Generator 

Grounded  pin  78  on  RRWDS  board 

Passed 

Passed 

On  menu  3.5,  “Signal  Processor  Misc.,”  thresholds  were  adjusted  to  induce  Signal  Processor 
power  supply  alarms  and  blowers  were  turned  off  to  exercise  blower  alarms.  BIT  and  FIT 
reported  correct  results  in  each  case.  WEC  recommended  fault  injection  techniques  produced  the 
correct  “Sync/Map”  BIT/FIT  results  as  shown  in  table  4. 1. 14.4-5. 

TABLE  4. 1 . 14.4-5.  “SYNC/MAP”  BIT/FIT  TEST  RESULTS 


Test 

Unit/LRU 

Fault  Method 

BIT 

FIT 

No. 

faulted 

Result 

Result 

1 

Radar  Control 

Removed  board 

Passed 

Passed 

2 

Radar  Triggers 

Inserted  faulty  chip  U62 

Passed 

Passed 

Removed  U1 

Passed 

Passed 

3 

Search  TTG 

Inserted  faulty  chip  U136 

Passed 

Passed 

4 

Frequency  Select 

Pulled  pin  19  high  on  U22 

Passed 

Passed 

Removed  U46 

Passed 

Passed 

5 

Clutter  Map 

Removed  Board 

Passed 

Passed 

6 

Detection  Map 

Removed  Board  • 

Passed 

Passed 

7 

Filter  Select 

Removed  Board 

Passed 

Passed 

8 

Map  Control 

Grounded  TP43 

Passed 

Passed 

9 

RRWDS 

Removed  U1 13  chip 

Passed 

Passed 

Grounded  TP34 

Passed 

Passed 

During  the  first  OT&E  phase,  “Det  Chan  1”  was  faulted  by  removing  the  Pulse  Compressor 
board.  Nineteen  minutes  elapsed  before  alarms  in  the  pulse  compressor  alarm  group  were 
observed  at  RMS.  The  BIT  reporting  time  was  excessive.  Retest  using  a  WEC  recommended 
fault  injection  technique  produced  the  BIT  alarm  in  6  minutes.  FIT  correctly  isolated  Detection 
Channel  1 .  Table  4. 1 . 14.4-6  shows  the  retest  results  for  “Det  Chan”  BIT/FIT.  All  tests  were 
successfiil. 


TABLE  4. 1 . 14.4-6.  “DET  CHAN”  BIT/FIT  TEST  RESULTS 


Test 

No. 

Unit/LRU 

faulted 

Fault  Metliod 

\ 

Result 

FIT 

Result 

1 

Pulse  Compressor 

Removed  U85 

Passed 

Passed 

2 

Doppler  Filter 

Inserted  faulty  chip  U27 

Passed 

Passed 

4 

Channel  Interface 

Grounded  pin  3  of  U62 

Passed 

Passed 

5 

CFAR 

Inserted  faulty  chip  U18 

Passed 

Passed 

On  menu  3.15,  “Data  Processor,”  thresholds  were  adjusted  to  induce  Data  Processor  power 
supply  alarms.  BIT/FIT  worked  accurately  in  detecting  and  isolating  the  faults.  Table  4.1.14.4-7 
shows  that  BIT/FIT  tests  on  the  Data  Processor  produced  acceptable  results. 

TABLE  4. 1 . 14.4-7.  “DATA  PROCESSOR”  BIT/FIT  TEST  RESULTS 


/;;;":.Test : " 

No. 

Unit/LRU 

faulted 

Fault  Method 

BIT 

Result 

FIT 

Result 

1 

CPUs 

Removed  CPU  boards  1,3,9 

Passed 

Passed 

2 

DP  Blowers 

Toggled  blower  power 

Passed 

Passed 

3 

GPROM 

Removed  board 

Passed 

Passed 

4 

Mode  4  Safe 

Opened  Safe  door 

Passed 

Passed 

5 

RDR  Display  Interface 

Removed  “RAPPI  IN”  cable 

Passed 

Passed 

6 

BCN  Display  Interface 

Removed  board 

Passed 

Passed 

7 

SIOs 

Removed  Modem  Cables 

Passed 

Passed 

The  GRAM,  Bus  Receiver  (BRX),  Radar  Interface  (RIB),  PMS/488/Disk,  and  Bus  Extender 
(BTX)  boards  could  not  be  removed  from  the  Data  Processor  without  locking  up  the  system. 
Therefore,  BIT/FIT  tests  for  these  boards  were  not  performed. 

Individual  alarms  were  not  verified  on  menu  3.16,  “Weather  Station,”  however,  the  weather 
station  was  faulted  to  exercise  bits  in  the  SOCC  status  message.  The  results  of  these  tests  are 
included  in  section  4.1.4  of  this  report. 

The  “Beacon/Mode  4”  BIT/FIT  tests  and  results  are  shown  in  table  4.1.14.4-8.  BIT/FIT  operated 
effectively  when  each  board  was  removed. 

One  serious  problem,  not  identified  during  a  formal  test  of  BIT/FIT,  is  described  below. 

In  April  1995,  start  of  the  regression  phase  of  OT&E  was  delayed  due  to  the  overall  instability  of 
the  ARSR-4.  Symptoms  included: 

a.  frequent  beacon  RTQC  “dropouts,”  where  the  injected  target  was  processed  and  reported 
outside  the  expected  RTQC  azimuth  window  and  not  properly  tagged  as  an  RTQC, 
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b.  an  instance  of  all  reported  beacon  targets  being  offset  by  30°  from  their  true  azimuth, 

c.  two  occasions  where  all  beacon  reports  were  reported  along  one  azimuth  for  one  scan. 

TABLE  4. 1 .14.4-8.  “BEACON/MODE  4”  BIT/FIT  TEST  RESULTS 


Test 

Unit/LRU 

Fault  Method 

BIT 

:  -i^iFlT. 

No. 

feulted 

Result 

Result 

1 

BCN  Video  Quantizer 

Removed  board 

Passed 

Passed 

BCN  Code  Extractor 

Removed  board 

Passed 

Passed 

BCN  CTRL  and  TTG 

Removed  board 

Passed 

Passed 

M4  Defruiter 

Removed  board 

Passed 

Passed 

M4CTRL 

Removed  board 

Passed 

Passed 

M4  Reply  Proc 

Removed  board 

Passed 

Passed 

1 _ 1 _ 

BCN  Defruiter 

Removed  board 

Passed 

Passed 

In  each  case,  BIT  failed  to  report  a  hard  alarm  and  FIT  did  not  isolate  the  problem.  Further 
troubleshooting  with  specialized  debug  equipment  revealed  that  four  faulty  boards  (one  Beacon 
Code  Extractor  (BCE),  one  BTX,  and  two  RIBs)  had  contributed  to  these  problems.  Changes 
were  later  made  to  make  the  BIT  tests  for  the  RIB  and  BCE  board  more  sensitive.  However,  no 
improvements  were  made  to  BTX  BIT  operation. 

Conclusions 

a.  BIT  (menu  3)  and  FIT  (menu  4)  test  all  major  functional  areas  of  the  ARSR-4. 

b.  BIT  responded  with  correct  results  when  thresholds  were  adjusted  to  induce  faults  in  the 
system. 

c.  The  board  removal  fault  injection  techniques  often  do  not  simulate  real-world  failures  of 
LRUs.  On  the  other  hand,  the  extent  to  which  Westinghouse  recommended  fault  injection 
techniques  simulate  real-world  failures  is  unknown. 

d.  The  case  of  four  faulty  boards  being  removed  from  the  system  without  an  alarm  shows  that 
ARSR-4  BIT/FIT  cannot  detect  all  possible  failures  of  LRUs  in  the  system. 

Recommendations 

BIT  and  FIT  should  not  be  used  as  the  sole  means  for  system  maintainability.  Maintenance 
procedures  (e.g.,  flowcharts)  should  be  developed  to  supplement  the  automatic  BIT  and  FIT 
functions  in  the  radar.  These  procedures  can  be  developed  based  on  the  existing  ARSR-4  design 
and  updated  as  more  failure  data  is  available  from  the  field. 
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4.1.14.5  Adjustable  Parameters  (RMS  Menu  S') 


Purpose 

Ensure  that  RMS  adjustable  parameters  provide  enough  flexibility  and  functionality  to  optimize 
the  system. 

Test  Objectives 

a.  Verify  that  sufficient  functionality  exists  in  the  ARSR-4  parameters  to  adjust  the  radar’s 
performance. 

b.  Verify  that  parameter  changes  change  system  performance  as  expected. 

Test  Description 

Commands  were  exercised  on  ARSR-4  RMS  menu  5,  “System  Operational  Parameters”  and  its 
submenus.  The  system  was  monitored  to  ensure  that  the  commands  operated  as  expected. 

Figure  4.1.14.5-1  shows  menu  5.  Site  and  field  adjustable  parameters,  operational,  and  adaptation 
parameters  were  verified  by  changing  parameter  values  in  the  10  major  operational  areas  at  menu 
5.  The  system  must  accept  parameter  values  within  specified  limits  and  reject  out-of-tolerance 
values.  Note  that  not  all  of  the  parameter  changes  made  an  obvious  change  to  the  system. 
Therefore,  the  effectiveness  of  those  parameters  were  not  verified. 


5  SYSTEM 

OPERATIONAL  PARAMETERS 

1. 

ANTENNA 

9. 

GENERAL  SETUP 

2. 

SEARCH  PROCESSING 

10. 

MPS  SETUP 

3. 

BEACON  PROCESSING 

4. 

MERGE  PROCESSING 

5. 

MODE  4  PROCESSING 

6. 

FORMATTER  /  I/O  SERVICES 

7. 

MAPS 

8. 

WEATHER  PROCESSING 

FIGURE  4.1.14.5-1.  RMS  MENU  5  -  SYSTEM  OPERATIONAL  PARAMETERS 


128 


Data  Analysis 

By  monitoring  alarms,  status,  LDC  video,  and  equipment  performance,  the  effect  of  parameter 
changes  were  confirmed. 

Results 

On  menu  5.1,  “Antenna,”  azimuth  offset  parameters  and  test  target  cable  loss  parameters  operated 
normally. 

On  menu  5.2,  “Search  Processing,”  most  parameters  were  successfully  verified.  The  RMS 
allowed  entry  of  all  expected  values  during  parameter  changes.  The  entries  ranged  from  minimum 
to  maximum  values  for  each  parameter.  However,  the  functional  effect  of  many  of  the  parameter 
changes  was  not  easily  noticed.  Those  areas  where  changes  produced  noticeable  effects  included 
the  transmitter  blanking  sectors,  search  and  weather  STC,  geocensor  range  extent,  search  RTQC, 
and  track  state  minimum  eligibility  factors. 

One  adverse  effect  was  noticed  during  setup  of  permanent  echo  zones  on  menu  5.2.3.  Although 
the  parameters  could  be  successfully  changed,  the  ARSR-4  only  intermittently  outputs  the 
permanent  echo  because  of  filtering  in  the  search  processor. 

On  menu  5.3,  “Beacon  Processing,”  beacon  detection,  runlength  discrimination,  beacon  tolerance, 
and  beacon  RTQC  parameters  were  verified  through  data  collection  and  analysis  to  operate 
effectively.  There  was  no  test  performed  with  different  beacon  PRFs. 

On  menu  5.4,  “Merge  Processing,”  values  in  merge  processing  were  accepted  by  the  system  and 
out-of-range  values  were  prohibited.  The  range  and  azimuth  parameters  at  menu  5.4.2  were 
changed  and  performance  changes  were  seen  on  the  RAPPI  and  performance  menus.  No  obvious 
change  in  scan-to-scan  statistics,  system  performance,  or  LDC  video  could  be  observed  for  any 
other  parameter  in  menu  5.4. 

On  menu  5.5,  “Mode  4  Processing,”  only  the  sector  transmission  inhibits  parameters  were  tested. 
Inhibit  zones  were  properly  displayed  on  the  LDC  RAPPI  when  these  parameters  were  exercised. 
The  remaining  functions  of  menu  5.5  were  tested  by  the  USAF. 

On  menu  5.6,  “Formatter/IO  Services,”  parameters  were  successfully  entered  and  accepted  by  the 
RMS. 

On  menu  5.7,  Map  parameters  were  successfiilly  exercised  during  the  site  optimization  when 
geocensor,  clear  day,  and  land/sea  maps  were  developed. 

On  Menu  5.8,  “Weather  Processing,”  all  parameter  changes  were  accepted  by  the  RMS. 

However,  the  functional  effects  of  some  of  the  changes  (including  adjustment  of  minimum 
weather  hole  and  vector  sizes)  were  not  seen  in  ARSR-4  operation. 

On  menu  5.9,  “General  Setup,”  parameters  were  verified  to  the  extent  that  this  site  permitted.  No 
Mode  S  was  present  at  the  site  and  the  Radar  Beacon  Performance  Monitor  (RBPM)  interface 
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was  not  functioning  at  the  time  of  testing.  Other  site  parameters  were  tested  as  normal  site 
optimization  procedures  were  performed. 

On  menu  5.10,  “MPS  Setup,”  the  Link  Address  and  SAP  Override  parameters  operated  as 
expected. 

Conclusions 

The  ARSR-4  parameters  provide  adjustments  for  the  major  functional  areas  of  the  system.  Not 
every  parameter  was  exercised,  however,  the  parameters  appear  to  be  adequate  to;  adapt  each  site 
to  local  conditions;  optimize  search,  beacon,  mode  4,  and  weather  processing;  and  configure  data 
transmission  to  up  to  20  different  users. 

Discussions  with  personnel  at  the  Los  Angeles  ARTCC  reveal  that  the  ARSR-4’ s  inability  to 
consistently  output  a  search  permanent  echo  is  not  an  operational  problem. 

4.1.14.6 _ Data  Extraction  (RMS  Menu  6). 

Purpose 

Ensure  that  the  data  extraction  subsystem  is  capable  of  extracting  data  from  the  operating  system 
in  real-time  and  recording  that  data  for  subsequent  off-line  reduction  and  analysis. 

Test  Objective 

a.  Verify  that  data  can  be  extracted  from  each  location  identified  in  RMS  menu  6. 1 . 

b.  Verify  that  data  extraction  has  no  adverse  impact  on  the  normal  operation  of  the  radar. 

Test  Description 

Data  was  extracted  from  different  points  in  the  ARSR-4  during  the  test.  Figure  4. 1 .14.6-1  shows 
RMS  menu  6.  The  menu  allows  for  initiation  of  up  to  four  simultaneous  data  extractions.  The 
extractions  can  be  set  up  for  a  user  designated  number  of  scans  or  can  be  allowed  to  extract 
continuously.  The  status  of  the  completed  scans  for  each  session  and  the  remaining  disk  space 
available  are  displayed  on  menu  6. 

Figure  4. 1.14.6-2  shows  the  data  extraction  categories  available.  Each  category  of  extraction  was 
exercised  and  a  confirmation  of  sufficient  recording  capacity  was  also  tested. 
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6  DATA  EXTRACTION 


ITEM  SESSION  1  SESSION  2  SESSION  3  SESSION  4 

ID  _  _  _  _ 

CATEGORY  _  _  _  _ 

START  _ : _ : _  _ : _ : _  _ : _ : _  _ : _ : _ 

STATUS  _  _  _  _ 

SCANS  COMPL _ _ _ _ 

1. ENTER  DATA  2 . ENTER  DATA  3 . ENTER  DATA  4 . ENTER  DATA 

92.  ENABLE  ALL  12. ENABLE  22. ENABLE  32. ENABLE  42. ENABLE 

93.  DISABLE  ALL  13. DISABLE  23. DISABLE  33. DISABLE  43. DISABLE 

94.  LOAD  ALL 

95.  CANCEL  ALL 

KBYTES  FREE 


FIGURE  4.1.14.6-1.  RMS  MENU  6  -  DATA  EXTRACTION  SETUP 


6.1 

EXTRACTION  TYPE 

SESSION:  1 

1. 

PULSE  COMPRESSOR  I/O 

6. 

HARDWARE  MAPS 

2. 

LOG  AMPLITUDE 

7. 

SOFTWARE  MAPS 

3. 

INPUTS  TO  SURVEILLANCE 

8. 

RADAR  CONTROL 

4. 

SURVEILLANCE  PROCESSING 

5. 

FORMATTER  AND  I/O  SERVICES 

FIGURE  4. 1 .14.6-2.  RMS  MENU  6. 1  -  DATA  EXTRACTION  TYPES 


Results 

Several  data  extraction  problems  were  noted  during  OT&E. 

a.  During  the  first  OT&E  phase,  a  four-session  data  extraction  was  attempted  while  the 
ARSR-4  had  low  target  loading  and  no  relevant  alarms.  The  hardware  extraction  session  stopped. 
Retest  on  July  3,  1995,  resulted  in  the  hardware  extraction  session  again  stopping.  Two 
additional  trials  had  the  same  result.  The  problem  only  affected  hardware  data  extractions.  All 
other  extraction  types  operated  normally.  There  were  no  adverse  effects  on  normal  ARSR-4 
operation. 
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b.  During  the  first  OT&E  phase,  a  hardware  extraction  caused  loss  of  redundancy  and  critical 
alarms  in  the  ARSR-4.  A  cold  start  was  necessary  to  return  the  system  to  normal  operation. 
Retests  on  June  22,  1995,  June  27,1995,  and  July  1,  1995,  could  not  duplicate  the  problem.  The 
system  responded  normally  in  each  case.  Software  changes  in  data  extraction  units  are  likely  to 
have  corrected  the  original  problem. 

Conclusions 

Data  extraction,  menu  6,  provides  a  basic  method  to  record  target  data  at  selected  processing 
points  in  the  ARSR-4  system. 

All  data  extraction  types  (except  hardware  extractions)  were  executed  reliably  from  the  RMS  with 
no  adverse  impact  to  normal  ARSR-4  operation. 

Hardware  data  extraction  sessions  often  terminate  prematurely.  Those  failure  modes  where 
hardware  extractions  caused  anomalies  in  normal  ARSR-4  operation  could  not  be  reproduced 
during  OT&E  regression  tests  with  the  25MAY95  software  build  in  the  system. 

Recommendations 

Data  extraction  functions  should  be  exercised  on  each  new  ARSR-4  software  build  to  ensure  that 
the  extractions  do  not  impact  normal  system  operation  and  operate  correctly. 

4, 1 . 14,7  Disk  Functions  (RMS  Menu  7V 
Purpose 

Verify  that  complete  hard  disk  operations  can  be  performed  by  displaying  software  segments, 
listing  and  deleting  files,  storing  and  loading  SAP/FAPs  and  Configuration  to/from  hard  disk. 

Test  Objectives 

Verify  that  the  fimctions  on  ARSR-4  RMS  menu  7,  “Disk  Functions”  operate  correctly. 

Test  Description 

Functions  were  exercised  on  ARSR-4  RMS  menu  7,  “Disk  Operations.”  The  system  was 
monitored  to  ensure  that  the  exercised  commands  operated  as  expected. 

Figure  4. 1 . 14.7-1  shows  RMS  menu  7.  The  menu  contains  options  which  allow  for  basic  disk 
maintenance  and  access  to  software  configuration  segments. 

Results 

The  list/delete  files  functions  at  menu  7.1  performed  as  expected. 

Software  segment  version  numbers  are  displayed  at  menu  7.2.  Checksums  for  the  current 
software  version  are  also  displayed.  Loading  software  segments  from  disk  to  Random  Access 
Memory  (RAM)  performed  normally. 

Parameter  and  Configuration  segments,  menu  7.3,  operated  as  expected. 
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7  DISK  OPERATIONS 

ENTER  PATH  FOR  DIRECTORY  DISPLAY: 

PAGE  NUMBER: 

C:\ 

1.  LIST/DELETE  FILES 

2.  SYSTEM  SEGMENTS 

3.  PARAMETER  AND  CONFIGURATION  SEGMENTS 

4.  MOUNT  DISK 

5.  PARK  DISK 

FIGURE  4. 1 . 14.7-1 .  RMS  MENU  7  -  DISK  OPERATIONS 


Conclusions 

Menu  7,  “Disk  Operations,”  provides  the  user  with  an  adequate  method  to  view,  delete,  and 
manage  files  on  the  system  hard  disk. 

Software  modules  (segments)  can  be  loaded  into  the  system  in  the  event  of  a  change,  update,  or 
failure  of  any  portion  of  the  operating  code. 

Provisions  to  remove  and  reinstall  the  hard  disk  work  adequately. 

4.1.15  Remote  Maintenance  Monitoring. 

Purpose 

Ensure  that  the  remote  monitoring  subsystem  of  the  ARSR-4  provides  sufficient  information  to 
allow  fault  isolation  and  system  certification  from  a  remote  location. 

Test  Objectives 

a.  Verify  that  the  ARSR-4  RMS  is  fail-safe  and  does  not  disrupt  any  radar  functions. 

b.  Verify  that  RMS  failure  alarms  and  diagnostics  are  made  available  to  the  MRS  via  RMMS. 

c.  Verify  that  the  ARSR-4  RMS  functions  as  an  integrated  component  of  the  RMMS. 

Test  Description 

This  section  describes  the  results  of  the  NAS  OT&E  Integration  retest  of  the  ARSR-4  RMS.  The 
initial  NAS  OT&E  Integration  test  was  performed  December  19,  1994,  through  February  13, 

1995. 

Retest  was  performed  from  June  5,  1995,  through  June  15,  1995,  using  the  ARSR-4  RMS  located 
at  Mt.  Laguna,  CA,  and  the  MPS  at  the  ARTCC  in  Palmdale,  CA.  The  ARSR-4  RMS  software 
version  used  during  testing  was  the  May  25,  1995  build.  The  ARTCC  MPS,  using  TANDEM 
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operating  system  version  C30.07,  was  running  version  R08. 1  of  the  Interim  Monitor  and  Control 
Software  (IMCS),  through  a  separate  PATHWAY.  An  LM-1  protocol  analyzer,  version  8.0  and 
the  enhanced  MPS  simulator,  version  1.01  were  used  as  test  tools. 

ARSR-4  to  MPS  interface  tests  were  conducted  by  the  Communication/Infrastructure  Branch, 
ACT-330,  at  the  Technical  Center.  BIT/FIT  verification  and  limited  fault  injection  were 
conducted  to  verify  that  the  remote  user  had  the  capability  to  control  the  system  and  received 
correct  status  information. 

Results 

The  NAS  OT&E  Integration  retest  closed  5  of  the  17  previously  open  Test  Trouble  Reports 
(TTRs)  and  identified  57  new  problems.  Seventeen  of  the  new  TTRs  were  subsequently  closed 
during  the  retest  period. 

Four  of  the  remaining  open  TTRs  were  classified  as  “critical.”  TTR-018-R1  identified  a  Global 
Status  command  that  causes  the  system  to  terminate  operation.  TTR-019-R1  identified  a  Specific 
Poll  to  Logical  Unit  3C  that  causes  the  system  to  terminate  operation.  TTR-022-R1  identified  a 
problem  with  IMCS  in  which  any  commands  above  data  point  4E  in  any  commandable  Logical 
Unit  are  not  accessible.  TTR-070-R1  identified  a  condition  where  IMCS  will  become  inoperable 
when  an  “ALL  COMMAND”  request  is  attempted.  Of  the  remaining  TTRs,  12  were  classified  as 
“major,”  16  were  classified  as  “minor,”  18  were  classified  as  “annoyance,”  and  2  were  classified 
as  “other.” 

Additional  RMMS  tests  were  performed  on  the  ARSR-4  after  the  OT&E  retest  period  described 
in  this  report.  Therefore,  more  detailed  information  can  be  found  in  the  ACT-330  final  report  on 
the  interface. 

Recommendations 

a.  ACT-330  does  not  recommend  deployment  of  the  ARSR-4  RMS  and  the  IMCS  decoder 
until  all  critical  and  major  TTRs  have  been  corrected  and  validated  during  a  retest. 

b.  ACT-330  also  recommends  correcting  all  the  minor  problems  and  addressing  the 
annoyances. 

4.1.16  ARSR-4  vs.  ARSR-3  Comparison. 

Purpose 

The  purpose  of  this  test  was  to  compare  the  performance  of  the  ARSR-4  with  the  performance  of 
the  existing  radar  at  Mt.  Laguna,  the  ARSR-3 .  Comparison  is  made  to  ensure  that  no  capability  is 
lost  with  the  introduction  of  the  ARSR-4  into  NAS. 

Test  Objective 

Verify  that  the  ARSR-4  meets  or  exceeds  the  performance  of  the  ARSR-3  while  meeting 
established  certification  thresholds. 
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Test  Description 

Targets  of  opportunity  from  the  ARSR-4  and  the  ARSR-3  were  simultaneously  recorded  at  the 
Los  Angeles  ARTCC  HOST  during  OT&E  regression  tests.  The  ARSR-4  was  configured  into 
VIP  mode  for  all  of  the  tests.  The  ARSR-3  was  operating  in  simplex. 

The  ARSR-3  operated  in  simplex  mode  during  OT«&E  (because  of  mutual  interference  with  the 
ARSR-4).  When  operated  in  simplex  mode,  the  ARSR-3  cannot  pass  some  of  the  QARS  tests 
with  the  diplex  thresholds.  A  waiver  was  made  to  use  ARSR-1/2  (less  stringent)  tolerances  during 
the  OT&E  to  allow  certification  of  the  ARSR-3. 

Data  Analysis 

HOST  QARS  was  performed  to  evaluate  system  performance.  QARS  was  performed  on  the 
following  dates:  June  14,  15,  16,  19-23,  26-29;  July  7,  10-13,  18-20,  26,  31;  August  1-4,  7,  1995. 
The  QARS  thresholds  established  for  the  ARSR-3  operating  in  diplex  mode  were  used  as  a 
measure  of  success  for  this  test. 

It  should  be  noted  that  the  blanked  areas  for  the  ARSR-4  and  ARSR-3  may  be  cause  for  some  of 
the  differences  in  performance.  Blanking  was  necessary  to  avoid  mutual  radar  interference.  The 
ARSR-4  transmitter  was  blanked  fi-om  326°  to  360°  in  azimuth.  The  ARSR-3  transmitter  was 
blanked  between  approximately  160°  and  180°. 

Results 

Tabular  results  of  QARS  analysis  on  ARSR-4  and  ARSR-3  data  are  included  in  appendix  C.  The 
most  stringent  QARS  fail  thresholds  were  chosen  for  inclusion  in  appendix  C  because  the  ARSR- 
4  should  be  able  to  meet  or  exceed  those  thresholds  established  for  ARSR-3  diplex  operation. 

Figures  4. 1 . 16-1  through  4. 1 .16-9  show  the  ARSR-4  and  ARSR-3  results  for  several  of  the 
QARS  measured  parameters.  Results  are  plotted  in  a  histogram  format  with  the  ARSR-4  and 
ARSR-3  results  presented  side  by  side.  Note  that  every  other  day  was  scaled  on  the  x-axis  of  each 
plot  in  order  to  improve  the  clarity  of  presentation. 

The  results  of  beacon  blip  scan  analysis  are  shown  in  figure  4.1.16-1.  The  results  show 
comparable  performance  with  both  radars,  with  ARSR-4  results  slightly  better  than  ARSR-3 
results  on  most  days.  Both  radars  consistently  exceeded  QARS  beacon  blip  scan  threshold. 

Search  blip  scan  results  are  shown  in  figure  4.1.16-2.  The  ARSR-3  shows  low  detection  due  to 
simplex  operation.  The  ARSR-4  search  blip  scan  compares  favorably  with  the  QARS  threshold 
(85  percent).  ARSR-4  results  were  above  92  percent  for  all  days. 

Reinforcement  results  are  shown  in  figure  4. 1 . 16-3.  The  effects  of  simplex  operation  are  again 
seen  in  the  low  ARSR-3  reinforcement  rate.  The  ARSR-4  reinforcement  rate  was  consistently 
above  92  percent  (well  above  the  QARS  85  percent  threshold). 
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Percentage  O  Percentage 


Beacon  Blip  Scan 


FIGURE  4.1.16-3.  ARSR-4  AND  ARSR-3  REINFORCEMENT  RATE  RESULTS 


Figure  4. 1 .16-4  shows  results  of  QARS  beacon  azimuth  split  analysis.  (Note:  The  y-axis  in  the 
plot  was  scaled  with  negative  values  for  data  presentation  purposes.  There  is  no  chance  for 
negative  split  percentages.)  The  ARSR-3  split  rate  remained  at  0  percent  throughout  the  test 
period.  On  the  other  hand,  the  ARSR-4  showed  varying  azimuth  split  percentages.  Note  that  in 
many  instances,  the  ARSR-4  beacon  azimuth  split  rate  exceeded  the  QARS  threshold  (0.1 
percent). 


Beacon  Azimuth  Splits 


FIGURE  4. 1 .16-4.  ARSR-4  AND  ARSR-3  BEACON  AZIMUTH  SPLIT  RESULTS 


Figure  4.1.16-5  shows  results  of  QARS  beacon  range  split  analysis.  The  ARSR-3  split  rate 
remained  at  0  percent  throughout  the  test  period  except  on  July  10,  1995,  when  the  QARS 
threshold  (0.1  percent)  was  exceeded.  On  several  days,  the  ARSR-4  split  rate  was  greater  than 
the  ARSR-3  rate.  The  ARSR-4  beacon  range  split  rate  reached  the  QARS  threshold  on  several 
days  and  exceeded  it  on  2  different  days. 


Cvj  co  oo 


Csl  CNl  OvJ 


to  to  to  to  to  to 


ARSR-3 
I  ARSR-4 


"  'Threshol  d 


OO  CO  CX3 


FIGURE  4. 1 . 16-5.  ARSR-4  AND  ARSR-3  BEACON  RANGE  SPLIT  RESULTS 


Mode  3/A  Reliability  results  are  displayed  in  figure  4.1.16-6.  Performance  is  comparable  between 
the  two  radars.  Each  radar  shows  results  well  above  the  QARS  threshold  (96  percent). 

Mode  3/A  Validation  results  are  displayed  in  figure  4.1.16-7.  On  most  days,  the  ARSR-3 
performed  slightly  better  than  the  ARSR-4;  however,  on  each  day  both  radars  met  or  exceeded 
the  QARS  threshold  (98  percent). 
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FIGURE  4.1.1 6-6.  ARSR-4  AND  ARSR-3  MODE  3/A  RELIABILITY  RESULTS 
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FIGURE  4.1.1 6-7.  ARSR-4  AND  ARSR-3  MODE  3/A  VALIDATION  RESULTS 


Mode  C  Reliability  and  Validation  results  are  shown  in  figures  4. 1 .16-8  and  4. 1 . 16-9.  All  numbers 
exceeded  QARS  thresholds  and  results  were  comparable  for  each  radar. 
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FIGURE  4. 1 . 1 6-8.  ARSR-4  AND  ARSR-3  MODE  C  RELIABILITY  RESULTS 
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M  ode  C  Validation 


FIGURE  4. 1. 16-9.  ARSR-4  AND  ARSR-3  MODE  C  VALIDATION  RESULTS 


Conclusions 

Beacon  blip  scan  results  indicate  that  the  ARSR-4  performed  slightly  better  than  the  ARSR-3  on 
most  days.  Both  radars  beacon  detection  exceeded  QARS  tolerances. 

Search  blip  scan  and  reinforcement  rate  results  show  that  the  ARSR-4  performed  better  than  the 
ARSR-3  on  each  day  that  data  was  collected.  The  lower  ARSR-3  search  detection  is  due  to 
simplex  operation.  On  each  day,  the  ARSR-4  exceeded  QARS  tolerances  in  both  categories. 

Beacon  azimuth  and  range  splits  were  higher  on  the  ARSR-4  than  on  the  ARSR-3.  On  some  days, 
the  measured  ARSR-4  split  percentages  exceeded  the  QARS  tolerances  while  the  ARSR-3  split 
percentages  remained  low.  Further  discussion  of  ARSR-4  split  rate  performance  is  presented  in 
section  4.1.11.1  of  this  report. 

Mode  3/A  and  Mode  C  validation  and  reliability  results  were  comparable  for  both  radars.  These 
results  surpassed  QARS  tolerances  on  each  day. 

Recommendations 

ARSR-4  beacon  parameter  settings  should  be  reexamined,  and  changed  if  necessary,  to  address 
the  high  split  rate.  If  further  parameter  optimization  does  not  solve  the  problem,  then  ARSR-4 
beacon  split  algorithms  may  need  to  be  modified.  If  the  algorithms  are  changed,  further  testing 
should  be  performed  to  verify  that  the  ARSR-4  meets  both  the  split  rate  and  beacon  resolution 
requirements. 

4.2  OT&E  OPERATIONAL  TESTS. 

OT&E  Operational  tests  evaluate  the  operational  effectiveness  and  suitability  of  the  ARSR-4 
when  operating  in  NAS. 

4.2. 1  Functional  Performance  -  Controller  Evaluations. 

Purpose 

Obtain  input  from  air  traffic  controllers  concerning  the  suitability  and  effectiveness  of  the  ARSR-4 
operating  in  NAS. 
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Test  Objective 

Verify  that  the  ARSR-4,  when  configured  in  NAS,  provides  at  least  the  capability  of  the  ARSR-3 
to  the  controller. 

Test  Description 

The  ARSR-4  performance  in  NAS  was  assessed  by  air  traffic  controllers  at  the  Los  Angeles 
ARTCC.  ARSR-4  target  of  opportunity  data  was  fed  to  the  controllers  during  the  test. 
Questionnaires,  which  addressed  the  fiinctional  performance  characteristics  of  the  radar  and  its 
interface  into  NAS,  were  filled  out  by  the  controllers. 

The  test  period  for  controller  evaluation  of  the  system  was  divided  into  precertification  and 
postcertification  tests. 

Precertification  tests  were  performed  with  the  ARSR-4  interfaced  to  DARC  and  the  ARSR-3 
interfaced  to  NAS.  In  this  configuration,  comparisons  between  the  radars’  performance  could  be 
made. 

Postcertification  tests  were  performed  when  the  ARSR-4  data  was  being  used  operationally  by 
Air  Traffic.  After  the  certification  flight  check,  the  ARSR-4  was  configured  as  the  primary  radar 
and  the  ARSR-3  as  the  secondary  radar  in  NAS. 

Data  Analysis 

Controllers  participated  in  development  of  the  questionnaires  as  well  as  responding  to  the 
questions.  The  questions  addressed:  general  ARSR-4/ ARTCC  interface  capabilities,  primary  radar 
coverage,  primary  radar  target  detection,  primary  radar  false  alarm  rate,  primary  radar  accuracy, 
range  and  azimuth  resolution,  BTP  code  validation  and  accuracy,  BTP  splits  and  false  reports, 
weather  detection  and  processing. 

Results 

The  questionnaires  and  controller  responses  are  included  in  appendix  D.  Controller  “Yes,”  “No,” 
or  “Not  Observed”  responses  to  each  question  are  included  along  with  any  additional  comments. 
The  unshaded  portions  of  the  appendix  tables  correspond  to  responses  fi'om  precertification  tests 
and  the  shaded  portions  from  postcertification  tests. 

“ARSR-4/ARTCC  Interface”  responses  indicate  that  the  ARSR-4  provides  the  basic  information 
needed  for  ATC.  During  precertification  tests,  the  ARSR-4  (interfaced  to  DARC)  provided  radar 
coverage  better  than  or  equal  to  that  of  the  ARSR-3  (interfaced  to  NAS)  in  areas  of  known  poor 
coverage. 

Responses  to  “Primary  Radar  Coverage”  questions  varied.  All  of  these  questions  were  asked 
during  post  certification  tests,  therefore,  no  comparison  could  be  made  between  the  ARSR-3  and 
the  ARSR-4  coverage.  The  blanked  area  in  the  direction  of  the  ARSR-3  tower  was  sometimes 
misinterpreted  as  a  coverage  hole  in  responses  to  some  questions. 
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Most  of  the  responses  to  “Primary  Radar  Target  Detection”  questions  were  “Not  Observed.” 

Responses  to  “Primary  Radar  False  Alarm  Rate”  questions  show  that  those  targets  determined  to 
be  false  by  controllers  do  not  have  an  adverse  effect  on  the  overall  control  of  AT. 

The  general  trend  in  responses  to  “Primary  Radar  Accuracy”  questions  indicate  that  the  ARSR-4 
provides  sufficiently  accurate  data  to  determine  the  range  and  azimuth  of  a  target  and  to 
adequately  separate  two  aircraft. 

Responses  to  “Range  and  Azimuth  Resolution”  questions  indicated  that  the  controllers  were  able 
to  meet  or  exceed  operational  separation  standards  on  those  targets  controlled  during  the  test 
(i.e.,  targets  of  opportunity). 

Responses  to  “Beacon  Code  Validation  and  Accuracy”  questions  indicate  that  the  identification 
processing  and  the  beacon  code  accuracy  of  ARSR-4  data  was  adequate  for  operational  use. 

Responses  to  “Beacon  Splits  and  False  Reports”  questions  show  that  splits  and  false  reports  were 
observed  during  the  tests.  This  data  is  consistent  with  split  results  presented  in  the  “ARSR-4  and 
ARSR-3  Comparison”  section  of  this  report. 

Responses  to  weather  detection  and  processing  questions  were  inconclusive  since  no  weather  was 
in  the  Mt.  Laguna  area  during  the  test  period. 

One  problem,  not  shown  in  responses  to  questionnaires,  arose  during  the  certification  flight  check. 
For  one  scan,  all  beacon  reports  from  the  ARSR-4  were  reported  along  the  same  azimuth.  The 
problem  corrected  itself  after  the  antenna  crossed  north.  The  problem  was  identified  as  an  AT 
safety  issue  by  controllers. 

Conclusions 

Controller  responses  to  questionnaires  indicate  that: 

The  ARSR-4  provides  the  basic  information  needed  for  use  in  ATC. 

a.  The  ARSR-4  provides  adequate  coverage  for  AT  use. 

b.  The  ARSR-4  data  was  accurate  and  allowed  resolution  of  those  targets  seen  during  the  test 
period. 

c.  The  ARSR-4  produced  beacon  splits  and  false  reports  that  were  noticed  by  the  controllers. 

The  problem  concerning  all  beacon  targets  reported  along  one  azimuth  was  identified  as  a  serious 
problem  by  controllers.  This  problem  was  first  noticed  in  March  1995,  and  was  not  seen  again 
until  the  certification  flight  check. 
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Recommendations 


Continued  observation  of  system  performance  should  continue  and  the  impact  of  the  beacon  splits 
and  false  reports  should  be  assessed  by  controllers. 

The  problem  concerning  all  beacon  targets  reported  along  one  azimuth  radial  should  be  addressed 
immediately.  The  fix  should  be  followed  by  a  demonstration  where  the  problem  can  be 
reproduced  when  the  radar  does  not  have  the  fix  and  cannot  be  reproduced  when  the  radar 
contains  the  fix  to  the  problem. 

4.2.2  Reliability.  Maintainability,  Availability. 

Purpose 

Ensure  that  the  ARSR-4  provides  data  in  a  reliable  manner  to  the  ARTCC  and  that  it  can  be 
maintained  by  site  technicians. 

Test  Objective 

a.  Verify  that  the  ARSR-4  achieves  a  mission  Mean  Time  Between  Critical  Failure  (MTBCF) 
of  1 500  hours  under  the  worst  case  environmental  conditions.  MTBCF  is  defined  as  the  total 
ARSR-4  uptime  divided  by  the  number  of  critical  hardware,  software,  and  firmware  failures  that 
degrade  Full  Mission  Capability  (FMC). 

b.  Verify  that  the  Mean  Time  Between  Failure  (MTBF)  is  greater  than  100  hours.  The 
MTBF  is  defined  as  the  total  ARSR-4  uptime  divided  by  the  total  number  of  hardware,  software 
and  firmware  failures  that  required  corrective  maintenance  action. 

Test  Description 

ARSR-4  reliability  was  assessed  for  the  OT&E  regression  period  from  June  5,1995,  through  July 
20,  1995.  Two  different  software  builds  were  loaded  in  the  system  during  that  time;  the 
25MAY95  and  13JUN95  builds.  The  13JUN95  build  was  loaded  into  the  system  on  July  8,  1995, 
to  correct  problems  associated  with  the  25MAY95  build. 

Data  was  collected  using  an  MPS  monitor  which  was  connected  to  the  ARSR-4  MPS  port 
between  June  5,  1995,  and  July  5,  1995.  The  MPS  monitor  recorded  alarm  and  reconfiguration 
data.  Any  system  anomalies  or  hardware  failures  were  noted  in  the  OT&E  test  and  maintenance 
logs. 

ARSR-4  maintainability  was  tested  through  verification  of  BIT/FIT  operation  and  the  ability  of 
technicians  to  perform  typical  maintenance  tasks.  During  BIT/FIT  verification,  faults  were 
injected  into  the  ARSR-4.  BIT  was  monitored  for  the  occurrence  of  an  alarm  and  FIT  was  used  to 
isolate  the  problem.  ARSR-4  trained  site  technicians  replaced  any  faulted  hardware  during  the  test 
period. 
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Data  Analysis 

The  MTBF  and  MTBCF  numbers  were  calculated  by  dividing  the  number  of  failures  by  the  total 
test  time. 

During  the  test  period,  the  ARSR-4  was  actively  operated  by  test  personnel  on-site.  Therefore, 
the  reliability  was  not  assessed  while  the  ARSR-4  operated  in  a  benign  user  environment. 

Through  correlation  of  log  book  entries  and  MPS  data,  those  failures  identified  as  being  caused  by 
test  personnel  were  not  counted  against  the  ARSR-4  in  the  reliability  assessment. 

Results 


Software  Reliability 

Three  serious  ARSR-4  problems,  not  observed  with  previous  software  builds  installed,  were 
discovered  after  the  25MAY95  software  build  was  installed; 

a.  Global  status  polls  issued  from  the  remote  MPS  caused  ARSR-4  system  crashes.  This  is  a 
critical  operational  failure. 

b.  Use  of  the  ARSR-4  search  test  target  generator  with  the  second  function  tracker  caused 
ARSR-4  system  crashes.  The  problem  was  readily  reproduced.  This  would  pose  a  critical 
operational  problem  if  site  technicians  used  test  targets  to  verify  system  performance  while 
providing  service  to  AT. 

c.  After  recovery  from  a  cold  start  or  short-term  power  loss,  false  BIT  hard  alarms  (Frequency 
Transition  alarms)  were  reported  for  both  synchronizers.  At  this  time,  the  ARSR-4  was  in  critical 
alarm.  The  output  of  false  BIT  alarms  is  a  critical  failure  and  is  cause  for  removal  of  the  radar 
from  NAS. 

To  enable  continued  testing  of  the  ARSR-4/MPS  interface,  the  13JUN95  software  build  was 
installed  at  Mt.  Laguna  on  July  8,1995.  The  build  fixed  the  problem  concerning  MPS  global  status 
polls  crashing  the  ARSR-4. 

Although  there  was  no  fix  for  the  STTG  problem  in  the  13JUN95  build,  that  problem  could  not 
be  duplicated  with  the  13  JUN95  build  installed  in  the  system. 

During  the  certification  flight  check  (with  the  13JUN95  build  installed),  an  anomaly  was  noted 
where  all  beacon  targets  were  reported  along  one  azimuth  for  one  scan.  Normal  beacon  reporting 
resumed  after  resynchronization  at  north.  This  “beacon  strobe”  problem  was  identified  as  an  AT 
safety  issue  by  controllers.  This  is  a  critical  operational  failure. 

Automatic  system  warm  starts  were  counted  for  the  time  when  the  MPS  monitor  was  connected 
to  the  system  (between  June  5,1995  and  July  5,1995).  In  this  period,  the  ARSR-4  experienced  69 
automatic  warm  starts  (approximately  2  per  day).  It  should  be  noted  that  interference  from  the 
collocated  ARSR-3  may  have  contributed  to  ARSR-4  warm  starts  and  reconfigurations. 
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The  ARSR-4  is  configured  with  10  CPUs,  with  an  eleventh  CPU  provided  for  redundancy. 

During  the  test  period,  there  were  eight  instances  where  one  CPU  was  not  available  for 
processing  data  (the  CPU  status  was  either  Unavailable-Faulted  (UA-F)  or  Standby  (STBY)). 

This  is  a  loss  of  redundancy.  There  were  two  instances  where  two  CPUs  were  unavailable  at  the 
same  time,  however,  there  was  no  observed  data  loss. 

In  six  of  the  cases  where  at  least  one  CPU  was  not  available,  a  cold  start  was  required  to  return 
the  CPU  to  On-line  (ONL).  The  cold  start  is  a  system  reset  which  takes  up  to  3  minutes  to 
complete.  In  one  case,  with  two  CPUs  in  STBY,  user  commanded  warm  starts  did  not  return  the 
CPUs  to  an  on-line  condition. 

Hardware  Reliability 

A  list  of  the  ARSR-4  hardware  replaced  during  the  retest  period  is  shown  in  table  4.2.2-1.  As 
seen  in  the  table,  there  were  several  instances  of  LDC  failures  during  the  test  period.  Although  an 
LDC  failure  does  not  impact  the  data  being  sent  to  the  ARTCC,  there  is  a  maintenance  impact 
when  an  LDC  has  failed.  The  use  of  a  MDT  as  a  backup  provides  system  control  capability  locally 
at  the  site,  however,  there  is  no  means  to  backup  PPI/RAPPI  capabilities  when  the  site  LDC  fails. 

The  failed  1 :3  splitter  was  most  likely  due  to  a  site  power  loss.  Additional  ARSR-4  power  loss 
related  problems  are  described  in  ARSR-4  to  Power  Subsystem  section  of  this  report. 

TABLE  4.2.2-1 .  HARDWARE  FAILURES  DURING  THE  RETEST  PERIOD 


IsEjatesH® 

Action  Taken 

6/05/95 

6/13/95 

6/16/95 

7/13/95 

7/18/95 

7/19/95 

Replaced  faulted  VDT  in  LDC  #1. 

Replaced  LNA  #10. 

Replaced  1:3  Splitter. 

Replaced  Down  Converter. 

LDC  #4  power  supply  replaced. 

LDC  #1  hung  up  during  flight  check.  Powder  reset  of  LDC  needed  to  restore  operation. 

Maintainability 

The  start  of  the  OT&E/DT&E  regression  tests  was  postponed  from  the  original  start  date  of  April 
17,  1995,  due  to  the  overall  instability  of  the  ARSR-4.  Symptoms  of  the  problems  included 
instances  of  CPU  dropouts,  data  reports  offset  by  approximately  30°  from  the  actual  azimuth,  and 
many  instances  of  beacon  RTQC  “dropouts”  in  the  data  sent  to  the  ARTCC. 

Westinghouse  engineers  dispatched  to  Mt.  Laguna  spent  3  weeks  troubleshooting  the  problems 
using  special  WEC  debugger  tools  (not  available  to  the  ARSR-4  site  technician).  Four  faulty 
boards  (one  BCE,  one  BTX,  and  two  RIBs)  were  removed  from  ARSR-4,  each  without  a  hard 
alarm  indication  from  BIT. 
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Several  other  maintenance  issues  were  revealed  during  testing: 


a.  ARSR-4  BIT  does  not  monitor  the  voltages  for  the  backup  batteries  for  the  Signal 
Processor  or  Data  Processor.  Adverse  effects  were  seen  when  power  was  interrupted  to  the 
ARSR-4  while  the  batteries  were  not  properly  charged.  More  detail  is  provided  in  the  ARSR-4  to 
Power  Subsystem  section  of  this  report. 

b.  Inspection  of  revision  levels  on  circuit  boards  in  the  system  reveals  that  there  is  no 
permanent  marking  on  the  boards  to  indicate  the  revision  level  of  the  board. 

c.  At  the  end  of  the  DT&E  phase  of  testing,  there  was  only  2  percent  spare  memory  available 
for  future  system  expansion. 

Conclusions 

a.  The  number  of  critical  operational  problems  encountered  during  the  test  period  was 
excessive.  The  critical  problems  associated  with  the  25MAY95  software  build  coupled  with  the 
“beacon  strobe”  problem  during  the  certification  flight  check  caused  the  MTBCF  to  be  greater 
than  one  every  1500  hours. 

b.  Problems  introduced  with  the  installation  of  new  software  builds  indicate  that  the  builds  are 
not  effectively  tested  at  the  factory  prior  to  delivery  to  the  field.  The  result  is  that  problems 
introduced  with  the  new  builds  may  impact  the  ability  of  the  ARSR-4  to  function  in  NAS. 

c.  The  “beacon  strobe”  problem  (the  reporting  of  all  beacon  targets  at  one  azimuth)  is  a 
serious  operational  problem  which  remained  in  the  system  at  the  end  of  OT&E. 

d.  The  average  of  approximately  two  warm  starts  per  day  is  most  likely  not  a  significant 
operational  problem. 

e.  The  ARSR-4’s  inability  to  automatically  restore  a  faulted  or  standby  CPU  to  on-line  status 
without  resetting  the  system  is  a  serious  operational  concern.  A  system  reset  (cold  start)  can  take 
up  to  3  minutes  to  complete.  During  this  time,  the  ARSR-4  is  not  available  for  use  in  NAS. 

With  CPUs  dropped  out  of  the  mix,  the  site  technician  must  decide  whether  to  cold  start  the 
system  (a  site  outage)  to  return  the  faulted  CPUs  or  wait  until  additional  CPUs  fault  before  taking 
action. 

f  The  LDC  was  unreliable  throughout  the  test  period. 

g.  The  ARSR-4  does  not  consistently  recover  from  a  short-term  power  loss. 

h.  With  the  exception  of  the  LDC  problems  or  power-related  hardware  problems,  the  ARSR-4 
hardware  was  reliable  during  the  test  period. 
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i.  In  general,  BIT/FIT  detected  and  isolated  those  problems  which  were  injected  into  the 
system  using  known  methods.  However,  BIT/FIT  did  not  detect/isolate  failures  in  four  boards  in 
the  data  processor  prior  to  start  of  the  retest.  This  indicates  that  not  all  possible  faults  were 
injected  into  the  system  during  testing.  The  level  of  BIT/FIT  effectiveness  in  detecting/isolating 
problems  with  faulted  boards  is  unknown. 

j.  The  labeling  of  revision  levels  on  the  circuit  boards  in  the  system  is  inconsistent  and 
confusing. 

k.  The  available  spare  memory  in  the  ARSR-4  will  not  be  sufficient  to  support  future  system 
corrections  or  upgrades. 

l.  The  status  of  backup  battery  voltages  is  not  reported  by  BIT.  Data  can  be  lost  to  the  user  if 
the  ARSR-4  experiences  a  power  loss  while  the  backup  batteries  are  faulty  or  uncharged. 

Recommendations 

a.  The  ARSR-4  should  not  be  operated  in  NAS  until  the  identified  critical  problems  have  been 
corrected  and  successfully  retested.  The  “beacon  strobe”  problem  should  be  corrected 
immediately.  Software  should  be  fixed  to  automatically  restore  faulted  and  standby  CPUs  to 
on-line  status  without  requiring  a  system  reset. 

b.  After  fixes  for  critical  problems  have  been  incorporated,  the  reliability  of  the  system  should 
be  assessed  over  an  extended  period  of  time.  The  ARSR-4  should  not  be  operated  in  an 
unmanned  environment  until  the  system  reliability  has  been  improved. 

c.  New  software  builds  should  be  fully  tested  at  the  factory  and  at  a  test  site  prior  to  reaching 
the  end  users  in  the  field.  Benchmark  tests  that  are  being  developed  for  this  purpose  should  be 
implemented  immediately.  The  benchmark  tests  should  be  fine  tuned  over  time  based  on  the 
effectiveness  of  the  tests.  When  the  Program  Support  Facility  (PSF)  becomes  available,  the 
resources  will  exist  to  provide  more  extensive  testing  of  new  builds. 

d.  The  number  of  automatic  warm  starts  and  reconfigurations  should  be  counted  again  when 
the  ARSR-4  is  not  collocated  with  the  ARSR-3.  The  operational  impact  should  then  be  assessed. 

e.  Since  the  LDC  reliability  was  poor  during  testing,  the  MDT  should  be  used  as  a  backup  for 
the  LDC  at  each  site.  A  decision  for  replacing  the  LDC  should  be  made  at  a  later  date  after  more 
reliability  data  has  been  collected. 

f  An  UPS  should  be  installed  on  every  ARSR-4. 

g.  Fault  detection  should  be  improved  for  the  four  boards  (1  BCE,  1  BTX,  and  2  RIBs) 
removed  from  the  system  prior  to  OT&E  retest.  ARSR-4  fault  detection  and  isolation  should  be 
improved  as  more  failure  data  is  compiled. 
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h.  BIT/FIT  should  not  be  used  as  the  only  means  to  maintain  the  ARSR-4.  An  alternate  plan 
(such  as  troubleshooting  flowcharts)  should  be  developed  to  assist  the  radar  technician  in 
troubleshooting  problems  when  BIT/FIT  do  not  detect  or  isolate  faults.  The  alternate  procedures 
should  be  incorporated  into  the  ARSR-4  site  technician  training  and  updated  as  more  failure  data 
is  compiled. 

i.  ARSR-4  circuit  boards  should  have  permanent  markings  of  serial  and  part  numbers  with  an 
accurate  revision  level  stamped  on  each  board. 

j.  The  spare  memory  available  in  the  ARSR-4  should  be  increased  to  support  system  upgrades, 
future  system  expansion,  or  corrections  for  any  future  problems. 

k.  The  frequency  of  maintenance  checks  should  be  increased  for  those  ARSR-4  components 
which  are  not  monitored  by  BIT  and  have  been  observed  to  fail  before  the  current  scheduled 
maintenance  check  was  performed  (such  as  the  backup  batteries  for  the  Signal  Processor  and  Data 
Processor). 

4.2.3  Site  Adaptation  and  Optimization. 

Purpose 

Evaluate  the  ability  to  optimize  the  ARSR-4  to  site  specific  conditions.  Determine  the  ability  of 
the  ARSR-4  to  adapt  to  environmental  changes  without  frequent  reoptimization. 

Test  Objective 

Verify  that  the  ARSR-4  can  be  optimized  using  standard  equipment  available  with  each  ARSR-4. 
Test  Description 

The  Mt.  Laguna  ARSR-4  was  optimized  by  AOS-230  and  USAF  personnel.  Site  adjustable 
parameters,  antenna  tilt,  and  site  maps  were  set  up  to  satisfy  the  coverage  requirements  of  the 
FAA  and  the  military.  Data  collection  and  analysis  were  performed  during  the  optimization 
process  to  verify  that  the  parameter  settings  were  correct. 

Data  Analysis 

ARSR-4  performance  was  monitored  throughout  OT&E.  Any  problems  related  to  incorrect  site 
optimization  or  adaptation  were  documented  in  the  test  log  book. 

Results 

The  ARSR-4  provided  sufficient  flexibility  in  the  site  adjustable  parameters  to  optimize  the  radar. 
However,  the  optimization  period  was  lengthy.  Since  the  Mt.  Laguna  ARSR-4  will  be  used  for 
FAA  and  USAF  applications,  several  iterations  of  parameter  adjustment,  data  collection,  and 
analysis  were  required  to  ensure  that  the  optimized  radar  satisfied  both  users’  requirements. 

One  problem  noted  during  OT&E  was  a  hole  in  coverage  to  the  east  of  the  site  (the  problem  and 
solution  are  detailed  in  section  4.1.6  of  this  report).  Changes  were  easily  made  to  geocensor  stop 
range  SAPs  to  address  the  coverage  problem.  However,  the  reduced  geocensor  thresholds  did  not 
completely  eliminate  the  problem. 
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A  second  problem  concerned  the  reporting  of  false  weather  to  controllers  during  periods  of 
anomalous  propagation.  The  ARSR-4,  as  configured,  did  not  adapt  to  the  environmental 
conditions.  However,  the  false  weather  was  not  identified  as  a  serious  operational  problem  at  the 
Los  Angeles  ARTCC. 

Conclusions 

The  ARSR-4  design  allows  the  system  to  be  optimized,  adapted  to  site  conditions,  and  certified. 
The  amount  of  time  required  to  optimize  future  systems  should  decrease  as  experience  is  gained  in 
the  optimization  process. 

The  ARSR-4  output  false  weather  to  the  user  when  anomalous  propagation  conditions  were 
prevalent.  The  false  weather  was  not  identified  as  a  serious  operational  problem  by  controllers  at 
the  Los  Angeles  ARTCC.  The  ability  of  the  ARSR-4  to  adapt  to  environmental  conditions  such 
as  anomalous  propagation  is  limited. 

Recommendations 

The  impact  of  false  weather  caused  by  anomalous  propagation  should  be  evaluated  at  each  site.  If 
the  false  weather  is  more  severe  at  other  locations,  causing  operational  problems,  steps  (either 
through  procedural  changes  or  redesign)  should  be  taken  to  ensure  that  the  ARSR-4  can 
automatically  adapt  to  these  environmental  conditions. 

4,2. 4  Human  Factors. 

Purpose 

Evaluate  user  interfaces  to  ensure  that  maintenance  and  operational  functions  can  be  effectively 
performed. 

Test  Objectives 

a.  Verify  that  the  systems’  equipment  design  conforms  to  human  engineering  design  criteria 
and  principles  to  achieve  safe,  reliable,  and  effective  performance  by  operator  and  maintenance 
personnel  and  to  minimize  personnel  skill  requirements  and  training  time. 

b.  Verify  that  ambient  noise  levels  are  tolerable  to  site  personnel  with  the  simultaneous 
operation  of  all  equipment,  including  the  I/O  devices. 

c.  Verify  that  all  ARSR-4  equipment  is  configured  so  as  to  provide  ready  access  for 
replacement  at  the  LRU  level. 

Test  Description 

Routine  maintenance  functions  were  observed  during  the  test  period  and  the  ease  with  which 
these  functions  could  be  performed  was  evaluated.  Any  anomalies  were  documented  in  the  test 
log  book  on  site.  Ambient  working  conditions  (lighting,  noise)  were  observed  and  any  problems 
noted. 
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Results 

The  circuit  boards  in  the  four  bay  are  easy  to  remove  and  install. 

The  RMS  screens  are  easily  traversed  via  the  LDC  or  MDT. 

The  lighting  in  the  ARSR-4  equipment  rooms  was  adequate  with  the  exception  of  the  RCJB, 
where  no  lighting  was  provided.  Therefore,  it  is  difficult  to  view  cabling  and  connections. 

The  ambient  noise  in  the  ARSR-4  transmitter  and  four  bay  rooms  was  noted  to  be  excessive.  A 
single  noise  baffle  was  positioned  on  the  Signal  Processor  cabinet.  The  baffle  significantly  reduced 
the  noise  level  from  the  Signal  Processor  cabinet  relative  to  adjacent  cabinets  and  produced  no 
apparent  adverse  effects  due  to  insufficient  air  flow  in  the  cabinet.  Other  baffles  were  on  order  at 
the  completion  of  testing. 

Conclusions 

ARSR-4  circuit  boards  are  easily  substituted  during  maintenance. 

The  lighting  is  adequate  in  the  ARSR-4  equipment  room  with  the  exception  of  the  RCJB,  where 
more  light  is  needed. 

The  addition  of  a  sound  baffle  on  the  Signal  Processor  cabinet  significantly  reduced  noise  from  the 
cabinet.  Addition  of  baffles  on  the  remaining  cabinets  should  significantly  reduce  ambient  noise  in 
the  transmitter  and  four  bay  rooms. 

4.2.5  Safety. 

Purpose 

Evaluate  the  ARSR-4  for  unsafe  conditions. 

Test  Objective 

Verify  that  system  equipments  are  designed  and  constructed  so  that  the  potential  for  personal 
injury  during  installation,  operation,  and  maintenance  is  minimized. 

Test  Description 

The  ARSR-4  and  its  environment  were  inspected  by  site  personnel  during  OT&E.  Any  unsafe 
conditions  were  documented  in  the  test  log  book  and  in  test  discrepancy  reports. 

Results 

Several  problems  associated  with  the  ARSR-4  power  installation  were  discovered: 

a.  Some  grounds  were  bonded  to  painted  surfaces. 

b.  The  cables  installed  to  ground  cabinets  in  the  four  bay  were  improperly  gauged  and  would 
not  handle  the  significant  current  required. 
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c.  A  neutral  wire  run  from  the  radar  power  panel  to  the  transmitter  room  was  left 
unterminated  in  a  raceway  in  the  transmitter  room. 

A  grounding  team  from  the  Western  Pacific  region  addressed  these  installation  problems  at  Mt. 
Laguna.  After  several  corrections  to  grounds,  the  team  reported  that  the  radar  was  safe. 

A  second  safety  issue  concerned  water  on  the  floor  in  the  antenna  deck.  Water  on  the  pedestal 
floor  causes  a  slipping  hazard,  particularly  when  the  water  freezes.  There  were  three  sources  for 
the  water.  The  first  source  was  a  leaking  radome.  Several  recaulking  attempts  by  the  radome 
subcontractor  proved  unsuccessful  in  stopping  these  leaks.  The  second  source  was  leakage 
through  the  pedestal  floor.  During  storms  with  high  winds  at  Mt.  Laguna,  water  is  forced  upward 
between  floor  panels.  The  third  source  for  the  water  was  entry  through  vents  in  the  radome. 

A  third  safety  issue  was  water  in  the  transmitter  room.  On  one  occasion,  during  a  storm,  the 
ARSR-4  was  turned  off  because  of  site  power  problems.  Power  was  not  restored  for  several  days. 
When  power  was  returned  to  the  system,  a  2:1:8  splitter  hard  alarm  was  reported  for  the 
transmitter.  Further  investigation  revealed  that  the  2:1:8  splitter  was  full  of  water. 

When  the  ARSR-4  power  was  turned  off,  the  louvers  on  the  exhaust  ducts  above  the  transmitter 
were  not  closed.  Rain  was  blown  into  the  duct  and  eventually  settled  in  the  transmitter  cabinet. 
The  battery  operated  louver  motor,  which  is  designed  to  close  the  exhaust  duct  louvers  upon  loss 
of  power,  did  not  function  because  the  battery  was  not  charged.  The  cause  for  the  uncharged 
battery  (either  a  bad  battery,  lack  of  maintenance,  or  improper  installation)  was  not  known.  The 
voltage  for  this  battery  is  not  monitored  by  BIT. 

After  another  storm,  a  puddle  was  found  on  the  floor  in  the  transmitter  room  under  the 
transmitter  circuit  breaker  panel.  The  water  leaked  from  the  louver  motor  enclosure  located  on 
the  wall  next  to  the  transmitter.  The  unit  was  recaulked.  However,  it  could  not  be  checked  due  to 
insufficient  rain  opportunities. 

Conclusions 

After  a  Western  Pacific  Region  power  team  corrected  improper  grounding  on  the  Mt.  Laguna 
ARSR-4,  they  deemed  that  the  ARSR-4  power/grounding  was  safe. 

Water  on  the  antenna  deck  can  cause  a  slipping  hazard. 

If  the  exhaust  duct  louvers  remain  open  when  the  air  handler  is  turned  off  during  a  rainstorm,  rain 
can  be  blown  into  the  transmitter  exhaust  duct  and  eventually  settle  in  the  transmitter.  This 
should  not  be  a  problem  under  normal  operating  conditions,  with  the  air  handler  on,  because  air 
pressure  from  the  air  handler  would  prevent  the  rain  from  blowing  into  the  duct. 
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Recommendations 

Careful  inspection  of  power/grounding  should  be  made  after  installation  of  every  ARSR-4. 

The  water/precipitation  leakage  onto  the  antenna  deck  should  be  corrected  to  prevent  a  personnel 
slipping  or  electric  shock  hazard. 

Since  BIT  does  not  monitor  the  louver  motor  battery  voltage,  the  frequency  of  maintenance 
checks  should  increase  for  these  batteries.  In  addition,  power  to  the  air  handler  should  not  be 
disconnected  during  rainstorms. 

4.2.6  Security. 

Purpose 

Evaluate  the  ARSR-4  system  design  for  security  of  classified  data  and  system  control. 

Test  Objectives 

a.  Verify  that  the  configuration  and  parameter  settings  of  the  ARSR-4  cannot  be  modified  by 
unauthorized  personnel. 

b.  Verify  that  the  ARSR-4  design  does  not  prohibit  operation  at  an  unmanned  site  due  to 
security  reasons. 

Test  Description 

Limited  security  tests  were  performed  by  ACT-310  personnel  through  inspections  of  RMS  menus 
on  the  LDC  which  require  a  security  clearance  and  through  testing  of  BIT  alarm  reporting 
associated  with  the  Mode  4  safe  door  and  KIR  status. 

Results 

Password  protection  is  available  for  ARSR-4  system  control  security  at  the  LDC  and  MDT. 

ACT-3 10  personnel  were  unable  to  access  classified  information  on  the  RMS  menus  without 
entering  a  password  for  access  to  the  LDC.  The  classified  information  located  in  the  Mode  4 
safes  was  secure.  The  safe  door  combination  locks  were  in  working  order.  In  addition,  the  built  in 
test  functions  related  to  the  safe  and  its  contents  worked.  The  proper  bits  were  set  in  the  SOCC 
status  message  when  the  safe  doors  were  opened  or  when  the  KIR  was  removed. 

Interlocks  for  the  antenna  door  and  radome  catwalk  door  functioned  correctly. 

Conclusions 

Limited  tests  performed  by  ACT-3 10  personnel  show  that  the  ARSR-4  classified  data  is  secure. 
Recommendations 

If  the  ARSR-4  radar  sites  go  to  unmanned  operation  or  if  site  manning  is  reduced,  site  procedures 
should  be  reevaluated  by  FAA  and  USAF  security  specialists  to  ensure  that  the  building  and  its 
contents  are  secure. 
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5. 


SIGNIFICANT  CONCLUSIONS 


The  conclusions  presented  in  this  section  are  based  on  Operational  Test  and  Evaluation  (OT&E) 
test  results.  Air  Route  Surveillance  Radar  Model  Four  (ARSR-4)  OT&E  was  conducted  at  Mt. 
Laguna,  California,  from  May  23,  1994,  through  January  15,  1995  (using  multiple  software 
builds)  and  from  June  1,  1995,  through  August  1 1,  1995  (using  the  25MAY95  and  13JUN95 
software  builds). 

a.  Results  showed  that  the  ARSR-4  performs  most  basic  surveillance  functions  well. 

Improved  ARSR-4  coverage  (when  compared  to  ARSR-3  coverage)  was  noted,  especially  in 
areas  with  a  history  of  poor  coverage.  Controller  responses  to  questionnaires  indicated  that  the 
ARSR-4  provides  the  basic  information  needed  for  use  in  air  traffic  control  (ATC). 

b.  The  ARSR-4  at  Mt.  Laguna  had  a  significantly  higher  beacon  split  rate  than  the  ARSR-3. 
The  higher  split  rate  often  exceeded  Quick  Analysis  of  Radar  Sites  (QARS)  tolerances  which  are 
used  to  certify  the  radar  in  the  National  Airspace  System  (NAS). 

c.  The  ARSR-4  did  not  perform  reliably  during  the  test  period.  The  number  of  critical 
operational  problems  encountered  was  excessive.  The  critical  problems  associated  with  the 
25MAY95  software  build  coupled  with  the  “beacon  strobe”  problem  (the  reporting  of  all  beacon 
targets  at  one  azimuth)  during  the  certification  flight  check  caused  the  Mean  Time  Between 
Critical  Failure  (MTBCF)  to  be  greater  than  one  every  1500  hours.  The  “beacon  strobe”  problem 
remained  in  the  system  at  the  end  of  OT&E.  The  problem  was  identified  as  a  serious  operational 
problem  by  controllers. 

d.  Problems  introduced  with  the  installation  of  new  software  builds  during  OT&E  indicated 
that  the  software  was  not  effectively  tested  at  the  factory  prior  to  delivery  to  the  field.  Ineffective 
factoiy  testing  may  impact  the  ability  of  the  ARSR-4  to  function  in  NAS. 

e.  The  ARSR-4,  as  configured  at  Mt.  Laguna,  did  not  consistently  recover  from  a  short-term 
power  loss  (less  than  15  seconds).  On  many  occasions,  the  ARSR-4  reported  a  large  number  of 
false  Built-in  Test  (BIT)  alarms  and  false  search  reports  after  power  loss.  The  safe  data  and 
configuration  segments,  routinely  saved  to  Electrically  Eraseable  Programmable  Read  Only 
Memory  (EEPROM)  during  a  power  loss,  can  become  corrupted  during  brownout  conditions. 
Also,  when  one  or  more  phases  of  site  power  are  dropped,  transmitter  hardware  is  often 
damaged. 

f  The  ARSR-4 ’s  inability  to  automatically  restore  a  faulted  or  standby  central  processing  unit 
(CPU)  to  on-line  status  without  resetting  the  system  is  a  serious  operational  concern.  A  system 
reset  (cold  start)  can  take  up  to  3  minutes  to  complete.  During  this  time,  the  ARSR-4  is  not 
available  for  use  in  NAS.  With  CPU(s)  dropped  out  of  the  mix,  the  site  technician  must  decide 
whether  to  cold  start  the  system  (a  site  outage)  to  return  the  faulted  CPUs  or  wait  until  additional 
CPUs  fault  before  taking  action. 

g.  In  general,  BIT/Fault  Isolation  Test  (FIT)  detected  and  isolated  those  faults  injected  into 
the  system  using  known  methods.  However,  BIT/FIT  did  not  detect/isolate  failures  in  four 
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boards  in  the  data  processor  prior  to  start  of  the  retest.  This  indicates  that  not  all  possible  faults 
were  injected  into  the  system  during  testing.  The  level  of  BIT/FIT  effectiveness  in 
detecting/isolating  problems  with  faulted  boards  is  unknown. 

h.  The  status  of  backup  battery  voltages  is  not  reported  by  BIT.  Data  can  be  lost  to  the  user  if 
the  ARSR-4  experiences  a  power  loss  while  the  backup  batteries  are  faulty  or  uncharged. 

i.  The  spare  memoiy',  available  in  the  ARSR-4  at  the  end  of  OT&E,  will  not  be  sufficient  to 
support  future  system  corrections  or  upgrades. 

j.  The  ARSR-4  successfully  completed  capacity  and  delay  tests  during  Development  Test  and 
Evaluation  (DT&E)  Software  Performance  Qualification  Test  (SPQT)  16.  Limited  OT&E 
capacity  and  delay  tests  showed  that  the  ARSR-4  can  process  and  provide  message  outputs  for  a 
steady  state  maximum  load  of  800  aircraft  returns  within  the  primary  radar  coverage  area  in  the 
Air  Traffic  Control  Beacon  Interrogator  (ATCBI)  configuration. 

k.  The  ARSR-4  met  the  2.2  square  meter  primary  range  and  azimuth  resolution  requirements 
(50  percent  requirement).  However,  the  ARSR-4  failed  10  square  meter  primary  range  and 
azimuth  resolution  tests  (a  more  stringent  90-percent  requirement).  The  ARSR-4  failed  to  resolve 
the  larger  targets  when  separated  by  greater  than  the  minimum  azimuth  resolution  requirements. 
Targets  with  an  azimuth  separation  of  2°  to  3°  which  also  have  a  range  separation  of  greater  than 
1/8  nautical  mile  (nm)  (but  less  than  1/4  nm)  are  resolved  only  between  25  and  40  percent  of  the 
time,  well  below  the  necessary  90-percent  resolution.  This  resolution  “hole”  indicates  a  problem 
in  the  ARSR-4  resolution  algorithms. 

l.  The  ARSR-4  weather  detection  and  reporting  capability  was  not  fully  evaluated  at  Mt. 
Laguna  due  to  the  unavailability  of  significant  weather  in  the  area.  Limited  tests  using  test  targets 
showed  that  the  ARSR-4  weather  processor  can  process  and  display  three  or  five  levels  of 
weather  on  the  Local  Display  Console  (LDC)  at  the  correct  position. 

The  Direct  Access  Radar  Channel  (DARC)  system  displays  ARSR-4  weather  information 
differently  than  the  HOST.  The  inconsistent  weather  processing  between  Air  Route  Traffic 
Control  Center  (ARTCC)  computers  is  not  suitable  for  ATC. 

m.  Full  control  of  the  ARSR-4  can  be  performed  from  any  terminal  (i.e.,  LDC,  Maintainence 
Display  Terminal  (MDT),  Transmitter  MDT  (TMDT))  at  the  local  site.  The  ARSR-4  Remote 
Monitoring  Subsystem  (RMS)  allows  the  site  technician  to  reconfigure  radar  elements,  monitor 
system  performance  and  initiate  internal  BIT  and  FIT  functions.  In  addition,  the  RMS  allows  for 
easy  adjustment  of  parameters  and  control  of  ARSR-4  data  extraction  functions. 

n.  The  ARSR-4  design  allows  the  system  to  be  optimized,  adapted  to  site  conditions,  and 
certified.  However,  during  OT&E,  the  ARSR-4  output  false  weather  to  the  user  when  anomalous 
propagation  conditions  were  prevalent.  This  indicates  a  limitation  in  the  ability  of  the  ARSR-4  to 
automatically  adapt  to  some  changing  environmental  conditions. 
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o.  The  ARSR-4  to  ARTCC  interface  operates  effectively.  The  ARSR-4  reports  all  expected 
message  types  in  the  correct  format  to  the  ARTCC.  The  ARSR-4  successfully  detects  failed 
modem  ports  and  automatically  reconfigures  redundant  serial  Input/Output  (I/O)  boards  on-line  in 
the  event  of  a  communications  failure.  Beacon  emergency,  Real-Time  Quality  Control  (RTQC), 
and  status  messages  are  correctly  given  priority  on  the  interface  during  buffer  overload  and  buffer 
overflow  conditions. 

p.  The  ARSR-4,  as  described  in  the  ARSR-4  to  Mode  Select  (Mode  S)  Interface  Control 
Document  (ICD),  will  not  interface  with  the  Mode  S  in  its  present  configuration.  In  addition,  test 
results  revealed  that  ARSR-4  status  is  not  correctly  reported  to  Mode  S  for  some  of  the  status 
bits. 

q.  The  ARSR-4  does  not  integrate  effectively  with  the  Radar  Remote  Weather  Display  System 
(RRWDS).  Several  problems  were  discovered  which  prohibit  an  effective  interface  between  the 
two  systems.  First,  the  ARSR-4  weather  video  voltage  levels  are  excessive.  Second,  the  RRWDS 
does  not  display  weather  at  the  correct  azimuth  due  to  the  coincidence  of  the  ARSR-4  generated 
Azimuth  Reference  Pulse  (ARP)  with  an  Azimuth  Change  Pulse  (ACP).  Third,  proper  alignment 
procedures  do  not  exist  for  the  ARSR-4/RRWDS  interface. 
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6. 


SIGNIFICANT  RECOMMENDATIONS 


a.  The  Air  Route  Surveillance  Radar  Model  Four  (ARSR-4)  should  not  be  operated  in  the 
National  Airspace  System  (NAS)  until  the  identified  critical  problems  have  been  corrected  and 
successfully  retested.  The  “beacon  strobe”  problem  (where  all  beacon  targets  are  reported  along 
one  azimuth  radial)  should  be  corrected  immediately.  Software  should  be  fixed  to  automatically 
restore  faulted  and  standby  Central  Processing  Units  (CPUs)  to  on-line  status  without  requiring  a 
system  reset.  After  fixes  for  critical  problems  have  been  incorporated,  the  reliability  of  the  system 
should  be  assessed  over  an  extended  period  of  time. 

b.  The  ARSR-4  should  be  operated  with  an  Uninterruptible  Power  Supply  (UPS)  in  addition 
to  a  reliable  backup  engine  generator  in  order  to  avoid  most  of  the  power  related  problems 
described  in  this  report.  In  addition,  there  should  be  capability  added  to  ARSR-4  Built-in  Test 
(BIT)  to  allow  monitoring  of  Signal  Processor  and  Data  Processor  backup  battery  voltages. 

c.  New  software  builds  should  be  fully  tested  at  the  factory  and  at  a  test  site  prior  to  reaching 
the  end  users  in  the  field.  Benchmark  tests  that  are  being  developed  for  this  purpose  should  be 
implemented  immediately. 

d.  BIT/Fault  Isolation  Test  (FIT)  should  not  be  used  as  the  only  means  to  maintain  the 
ARSR-4.  An  alternate  plan  (such  as  troubleshooting  flowcharts)  should  be  developed  to  assist 
the  radar  technician  in  troubleshooting  problems  when  BIT/FIT  do  not  detect  or  isolate  faults. 

The  alternate  procedures  should  be  incorporated  into  the  ARSR-4  site  technician  training  and 
updated  as  more  failure  data  is  compiled. 

e.  The  spare  memory  available  in  the  ARSR-4  should  be  increased  to  support  system 
upgrades,  future  system  expansion,  or  corrections  for  any  future  problems. 

f  The  cause  for  the  high  ARSR-4  beacon  split  rate  at  Mt.  Laguna  should  be  identified  and 
corrected.  ARSR-4  beacon  parameter  settings  should  be  reexamined,  and  changed  if  necessary, 
to  address  the  high  split  rate.  If  further  parameter  optimization  does  not  solve  the  problem,  then 
ARSR-4  beacon  split  algorithms  may  need  to  be  modified.  If  the  algorithms  are  changed,  further 
testing  should  be  performed  to  verify  that  the  ARSR-4  meets  both  the  split  rate  and  beacon 
resolution  requirements. 

g.  The  operational  significance  of  the  range  resolution  hole  between  1/8  nautical  mile  (nm)  and 
1/4  nm  should  be  evaluated  by  Air  Traffic  (AT)  personnel.  If  the  hole  is  deemed  to  be  an 
operational  problem,  then  corrections  should  be  made  to  the  ARSR-4  resolution  algorithms  and 
those  fixes  should  be  retested. 

h.  Direct  Access  Radar  Channel  (DARC)  weather  processing  should  be  corrected  to  coincide 
with  the  weather  processing  in  NAS  so  that  consistent  weather  information  is  reported  to  the 
controller  when  the  backup  system  is  switched  on-line.  In  addition,  fiirther  weather  tests  should 
be  conducted  at  another  ARSR-4  site  where  weather  is  more  prevalent.  ARSR-4  weather 
products  should  be  compared  to  weather  products  from  National  Weather  Service  (NWS)  radars 
to  verify  accurate  weather  reporting. 
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i.  The  impact  of  false  weather  caused  by  anomalous  propagation  should  be  evaluated  at  each 
site.  If  the  false  weather  is  more  severe  at  other  locations,  causing  operational  problems,  steps 
(either  through  procedural  changes  or  redesign)  should  be  taken  to  ensure  that  the  ARSR-4  can 
automatically  adapt  to  these  environmental  conditions. 

j.  The  ARSR-4/Mode  Select  Beacon  System  (Mode  S)  Interface  Control  Document  (ICD) 
and  ARSR-4  system  design  should  be  corrected  to  enable  interface  with  the  Mode  S.  A  full 
integration  test  is  recommended  for  the  first  site  which  has  an  ARSR-4  and  a  Mode  S.  The  test 
should  include  data  throughput,  format  verification,  capacity  and  delay,  channel  switching,  and 
Mode  S/Mode  4  compatibility  tests. 

k.  Consideration  should  be  given  to  eliminating  the  Radar  Remote  Weather  Display  System 
(RRWDS)  from  the  ARSR-4  weather  path  to  the  Air  Route  Traffic  Control  Center  (ARTCC). 
Digital  weather  messages  from  the  ARSR-4  six  level  weather  processor  should  be  sent  directly  to 
the  ARTCC.  This  approach  would  require  changes  to  the  ARSR-4  formatter  and  the 
development  of  a  weather  video  reconstitutor  for  location  at  the  ARTCC. 
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7. 


ACRONYMS  AND  ABBREVIATIONS. 


ACP 

Azimuth  Change  Pulse 

AGL 

Above  Ground  Level 

APG 

Azimuth  Pulse  Generator 

APMT 

Associate  Program  Manager  for  Test 

ARP 

Azimuth  Reference  Pulse 

ARSR-4 

Air  Route  Surveillance  Radar  (Model  4) 

ARTCC 

Air  Route  Traffic  Control  Center 

ASR-9 

Airport  Surveillance  Radar  (Model  9) 

AT 

Air  Traffic 

ATC 

Air  Traffic  Control 

ATCBI 

Air  Traffic  Control  Beacon  Interrogator 

BAM 

Burst  Agile  Mode 

BCE 

Beacon  Code  Extractor 

BCOL 

Beacon  Channel  On-line 

BER 

Block  Error  Rate 

BEXR 

Beacon  Extractor  and  Recorder 

BIT 

Built-In  Test 

BMI 

Basic  Measurement  Instruments 

BO 

Beacon  Only 

BRTQCA 

Beacon  Real-Time  Quality  Control  Alarm 

BRX 

Bus  Receiver  Board 

BTP 

Beacon  Target  Processor 
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BTX 

Bus  Extender  Board 

CD-2 

Common  Digitizer  2 

COI 

Critical  Operational  Issue 

COTS 

Commercial-Off-The-Shelf 

CPU 

Central  Processing  Unit 

CQMS 

Circuit  Quality  Monitoring  System 

CW 

Constant  Wave 

DARC 

Direct  Access  Radar  Channel 

dB 

decibel 

DCE 

Data  Communication  Equipment 

DT&E 

Development  Test  and  Evaluation 

DTE 

Data  Terminal  Equipment 

EARTS 

Enroute  Automated  Radar  Tracking  System 

EEPROM 

Electrically  Eraseable  Programmable  Read  Only  Memory 

EMI 

Electromagnetic  Interference 

FAA 

Federal  Aviation  Administration 

FACSFAC 

Fleet  Area  Control  Surveillance  Facility 

FAP 

Field  Adjustable  Parameter 

FIT 

Fault  Isolation  Test 

FMC 

Full  Mission  Capability 

FRUIT 

False  Replies  Unsynchronous  In  Time 

GFE 

Government  Furnished  Equipment 

GPS 

Gobal  Positioning  System 
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GRAM 

Global  Random  Access  Memory 

GSV 

General  Site  Verification 

Hz 

hertz 

IBI 

Interim  Beacon  Interrogator 

ICD 

Interface  Control  Document 

IF 

Intermediate  Frequency 

IMCS 

Interim  Monitor  and  Control  Software 

I/O 

Input/Output 

lOT&E 

Independendent  Operational  Test  and  Evaluation 

IP 

Interpulse  Period 

IRES 

Integrated  Radar  Evaluation  System 

ISM 

Integral  Systems  Monitor 

LDC 

Local  Display  Console 

LNA 

Low  Noise  Amplifier 

LRU 

Logical  Replaceable  Unit 

M4ALA 

Mode  4  Alarm 

MDS 

Minimum  Discernable  Signal 

MDT 

Maintainence  Display  Terminal 

MHz 

megahertz 

Mir  coE  ARTS 

Microprocessor-based  Enroute  Radar  Tracking  System 

MODE-S 

Mode  Select  Beacon  System 

MPS 

Maintenance  Processor  System 

PS 

microsecond 
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ms 

millisecond 

MSL 

Mean  Sea  Level 

MTBCF 

Mean  Time  Between  Critical  Failure 

MTBF 

Mean  Time  Between  Failure 

MTI 

Moving  Target  Integrator 

NAS 

National  Airspace  System 

NCP 

NAS  Change  Proposal 

nm 

nautical  mile 

ns 

nanosecond 

NWS 

National  Weather  Service 

ONL 

On-line 

ORD 

Operational  Requirements  Document 

OT&E 

Operational  Test  and  Evaluation 

P04STA 

Port  Status  Alarm 

PAM 

Pulse  Agile  Mode 

PE 

Permanent  Echo 

PPI 

Plan  Position  Indicator 

PRF 

Pulse  Repetition  Frequency 

PRT 

Pulse  Repetition  Time 

PSF 

Program  Support  Facility 

PULS 

Pulse  Agile 

QARS 

Quick  Analysis  of  Radar  Sites 

RADES 

84th  Radar  Evaluation  Squadron 
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RAM 

Random  Access  Memory 

RAPPI 

Random  Access  Plan  Position  Indicator 

RB 

Radar  Beacon  Merge 

RBPM 

Radar  Beacon  Performance  Monitor 

RCJB 

Radar  Control  Junction  Box 

RCS 

Radar  Cross  Section 

RF 

Radio  Frequency 

RFBITS 

Radio  Frequency  Beacon  Interrogator  Test  Set 

RHI 

Range  Height  Indicator 

RIB 

Radar  Interface  Board 

RLS 

Radar  Line  of  Site 

RMMS 

Remote  Maintenance  Monitoring  Subsystem 

rms 

root-mean-squared 

RMS 

Remote  Monitoring  Subsystem 

RO 

Radar  Only 

RR 

Radar  Reinforced 

RRWDS 

Radar  Remote  Weather  Display  System 

RTQC 

Real-Time  Quality  Control 

SAP 

Site  Adjustable  Parameter 

SCV 

Sub-clutter  Visability 

SIO 

Serial  Input  /  Output 

SOCC 

Sector  Operations  Control  Center 

SPI 

Special  Position  Identification 
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SPQT 

Software  Performance  Qualification  Test 

STAC 

Second  Time  Around  Clutter 

STBY 

Standby 

STC 

Sensitivity  Time  Control 

STTG 

Search  Test  Target  Generator 

TDK 

Test  Discrepancy  Report 

TIS 

Time  In  Storage 

TMDT 

Transmitter  Maintenance  Display  Terminal 

TQA 

Track  Quality  Assessment 

TTR 

Test  Trouble  Report 

UA-F 

Unavailable  /  Faulted 

UPS 

Uninterruptable  Power  Supply 

USAF 

United  States  Air  Force 

VDT 

Video  Display  Terminal 

VideoBITS 

Video  Beacon  Interrogator  Test  Set 

VIP 

Variable  Interpulse  Period 

VSWR 

Voltage  Standing  Wave  Ratio 

WEC 

Westinghouse 

WXCHST 

Weather  Channel  Status 
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APPENDIX  A 


TEST  DISCREPANCY  REPORT  (TDR) 
SUMMARY 


OT&E  TEST  DISCREPANCY  REPORT  SUMMARY 


To  track  and  identify  each  test  failure  or  system  problem  discovered  during  OT&E,  TDRs  were 
developed.  These  reports  identify  the  test  in  progress,  ARSR-4  software  build  in  use,  criticality  of 
the  problem,  a  description  of  the  problem/failure,  and  recommended  course  of  action. 

Table  1 .  provides  a  summary  of  the  155  TDRs  written  by  ACT-3 10  during  the  OT&E  test  period. 
Included  in  this  table  is  the  TDR  number,  the  date  the  TDR  was  developed,  a  brief  description, 
the  criticality  of  the  problem,  and  the  closure  status. 

Problem  criticality  is  listed  as  Serious.  Moderate,  or  Minor.  Serious  problems  include  those  items 
which  must  be  corrected  for  the  ARSR-4  to  properly  operate  as  part  of  the  NAS.  Those  TDRs 
with  Serious  criticality  which  remain  open  after  completion  of  retest  are  shaded  in  the  Criticality 
column  of  the  table. 

Moderate  problems  are  those  which  primarily  effect  user  ability  to  maintain  the  radar.  Problems 
identified  as  Minor  are  those  discrepancies  which  are  an  annoyance  and  result  in  increased  work 
for  the  end  user. 

The  TDR  status  definitions  include:  Open,  Closed,  or  Retest.  The  "Open"  status  identifies 
problems  which  have  no  agreement  with  WEC  to  correct.  The  "Retest"  status  classifies  those 
items  which  are  believed  by  WEC  to  be  corrected  through  software  or  hardware  changes  to  the 
ARSR-4,  or  items  that  WEC  could  not  duplicate  which  may  have  been  fixed  by  software  changes 
during  OT&E.  Finally,  discrepancies  marked  as  "Closed"  were  corrected  through  system 
modifications  and/or  contractor  documentation,  and  verified  through  retest. 

A  few  items  contain  a  status  which  is  not  listed  in  the  previous  paragraph.  AOS  will  implement  a 
fix  to  the  problem  identified  in  TDR  #1 1  using  COTS  components.  Retest  will  be  conducted  with 
the  AOS  implementation.  The  Overflow  errors  on  RRWDS  referenced  in  TDR  #12  are  probably 
not  an  operational  concern.  However,  the  impact  on  the  maintenance  of  the  RRWDS  needs  to  be 
determined. 


A-1 


Table  i :  OT&E  Tesf  Discrepancy  Reports  {May  23, 1994  Ihrougl 

TOR# 

Date 

Description  of  TOR 

1 

6/7/94 

Port  6  and  7  RCJB  jack  assignment  reversal 

2 

6/7/94 

Data  Extraction  aborts  with  Synchronizer  Reconfiguration 

3 

6/7/94 

RTQC  Target  Dropouts 

4 

6/7/94 

Data  not  Distributed  over  remaining  ports  when  a  port  fails 

5 

6/7/94 

LP/CP  status  does  not  function  in  Status  Message  to  ARTCC 

6/7/94 

WXCHST  field  always  indicates  Wx  channel  as  Failed 

n 

6/7/94 

BIT  not  alarming  on  unterminated  user  ports  (ie.  failed  port) 

8 

6/7/94 

FIT  does  not  isolate  a  failed  user  port 

9 

6/7/94 

Incorrect  MPS  message  when  FIT  runs  on  Data  Processor 

10 

6/8/94 

Low  System  Reliability  (3  Critical  Failures  and  87  WS  over  21  days) 

11 

6/23/94 

Excessive  RRWDS  Video  Levels  from  the  ARSR-4 

12 

6/23/94 

Overflow  errors  indicated  on  RRWDS  when  connected  with  ARSR-4 

13 

6/23/94 

Two  additional  Critical  failures  since  6/7/94  (3  scan  WS  with  CPU  loss) 

14 

6/23/94 

Three  LDC/RMS  Terminal  lockups,  One  LDC/RAPPI  Lockup 

15 

6/23/94 

Failure  to  recover  from  Power  Loss  (Weather  Station  Alarms) 

16 

6/23/94 

Task  Time-out  loading  Geocensor  Map,  Cold  Started  to  recover 

17 

6/23/94 

RMS  Stuck  in  Menu  5.2 

18 

7/1/94 

DE  would  not  run  after  performing  FIT  during  a  previous  DE 

19 

7/1/94 

Test  Targets  do  not  shut  OFF  when  switching  from  MAINT  to  REPR 

20 

7/1/94 

LDC  locked  up  when  printing  a  RMS  menu  screen 

21 

7/1/94 

Intermittent  RRWDS  Video  alarm  with  ARSR-4  connected  to  RRWDS 

22 

7/18/94 

BRX  Boards  are  not  redundant  (ie.  single  point  of  failure) 

23 

7/18/94 

Military  Emergency  Bit  set  on  non-emergency  targets 

24 

7/18/94 

BETAPR  field  Is  reporting  incorrect  status  to  the  ARTCC 

25 

7/18/94 

Data  Processor  indicates  100%  operational  with  the  BCE  board  removed 

26 

7/18/94 

System  lockup  and  target  losses  when  switching  Wx  and  STBY  Detection 

27 

7/18/94 

WXCHST  field  reporting  incorrect  status  when  WX  channel  failed 

28 

7/18/94 

OLBA  failed  to  alarm  when  quantized  video  from  ATCBI  was  removed 

29 

7/18/94 

M4ALA  alarm  did  not  occur  with  Mode  4  transmission  in  a  prohibited  sector 

30 

7/18/94 

OLRBAL  did  not  alarm  with  the  RBPM  enabled  but  disconnected 

31 

7/18/94 

OUSRA*,  TIS,  BOA,  BOFA  were  not  reported  with  these  conditions 

32 

7/18/94 

DM  CH*  STC/Bird  WX  Map  Verify  alarms  on  RMS,  Cold  Start  needed 

33 

7/18/94 

SRTQC  alarm  was  not  reported  to  the  ARTCC 

34 

7/20/94 

Polarization  changes  are  not  being  reported  in  the  POLCHA  field 

Pre^DRR 


Crtlicsdlty 

Status 

Minor 

Closed  (6/10/94) 

Minor 

Open 

SERIOUS 

Closed  (7/14/95) 

SERIOUS 

Closed  (7/6/95) 

SERIOUS 

Closed  (6/15/95) 

SERIOUS 

Closed  (8/31/94) 

Moderate 

Closed  (6/15/95) 

SERIOUS 

Closed  (6/15/95) 

Moderate 

Closed  (6/28/95) 

SERIOUS 

Open 

AOS  to  implement 

Minor 

Determine  impact 

SERiOUS 

Open 

SERiOUS 

Open 

SERIOUS 

Closed -See  TDR  151 

Moderate 

Open 

Minor 

Closed  (6/28/95) 

Moderate 

Closed  (6/28/95) 

Minor 

Open 

Open 

SERIOUS 

Closed  (7/14/95) 

Moderate 

Closed  (11/11/94) 

SERIOUS 

Closed  (6/28/95) 

SERIOUS 

Closed  (6/15/95) 

Moderate 

Closed  (6/28/95) 

SERIOUS 

Closed  (6/28/95) 

SERIOUS 

Closed  (6/15/95) 

Moderate 

Closed  (11/11/94) 

SERIOUS 

Closed  (6/15/95) 

Moderate 

Closed  (7/14/95) 

SERIOUS 

Closed  (7/6/95) 

Moderate 

Closed  (7/14/95) 

SERIOUS 

Closed  (6/15/95) 

SERIOUS 

Closed  (6/15/95) 

table  1 :  Qt&£  Test  Discr^anoy  Reports<May  23,  i994through  August  1 1995) 

TOR# 

Date 

35 

7/20/94 

36 

7/20/94 

37 

7/20/94 

38 

7/20/94 

39 

7/20/94 

40 

7/20/94 

41 

7/20/94 

42 

7/20/94 

43 

7/20/94 

44 

7/20/94 

45 

7/20/94 

46 

7/20/94 

47 

7/20/94 

48 

7/20/94 

49 

8/16/94 

50 

8/16/94 

51 

8/16/94 

52 

8/16/94 

53 

8/16/94 

54 

8/16/94 

55 

8/16/94 

56 

8/16/94 

57 

8/16/94 

58 

8/16/94 

59 

8/16/94 

60 

8/16/94 

61 

8/16/94 

62 

8/16/94 

63 

8/31/94 

64 

8/30/94 

65 

8/30/94 

66 

8/30/94 

67 

8/30/94 

68 

8/30/94 

69 

8/30/94 

Oescrpion  of 


Mode  4  operation  changes  not  reported  in  the  SUM40N  field 


Output  service  alarms  are  not  being  reported  In  the  MODALA  field 


SRTQCA  alarm  was  not  reported  to  the  SOCC 


BETAPR  field  did  not  report  an  alarm  to  the  SOCC  with  beacon  video 


BOFA  and  USRALA  alarms  not  reported  to  SOCC  when  ports  overflow 


KRSTAT  and  M4PRST  alarms  were  not  reported  to  the  SOCC 


FRSOST  alarm  was  not  reported  to  the  SOCC  with  a  freq  gen  alarm  on 


Incorrect  alarm  threshold  adjustments  reported  to  the  MPS 


DEFKA  bit  to  the  SOCC  does  not  function 


M4INOR  and  M4ALA  alarms  did  not  report  a  prohibited  Mode  4 


Loss  of  receiver  redundancy  was  not  reported  in  the  RCVSTA  field 


A  critical  DP  failure  was  not  reported  in  the  DPR  I  ST  field  to  the  SOCC 


SPSTAT  field  did  not  report  a  loss  of  redundancy  to  the  SOCC 


Loss  of  redundancy  was  not  reported  in  the  TXSTAT  field  to  the  SOCC 


Received  a  faulty  error  message  when  calibrating  the  RF  ports 


RF  power  readings  on  the  RMS  do  not  update  when  no  RF  is  transmitted 


Pedestal  HA's  did  not  clear  when  thresholds  were  returned  to  normal 


Transmitter  HA's  did  not  clear  when  thresholds  were  returned  to  normal 


Radome  Obstruction  Light  A  is  reporting  a  HA  with  the  light  illuminated 


MDT  failure  resulted  in  a  complete  loss  of  system  control 


RC  CH*  STC  EEPROM  Checksum  HA’s  present  and  could  not  be  cleared 


ARSR-4  automatically  cold  started  when  commanding  an  STC  load 


Data  Extraction  indicates  pause  during  non-capacity  loading 


Time  Clock  on  RMS  menu  6  halted  when  the  MDT  accessed  menu  6 


The  Index  of  Refraction  and  Ka  values  are  not  updating  from  a  cold  start 


The  LDC/RMS  locked  up  when  entering  a  DE  filename 


The  PPl/RAPPI  display  size  did  not  change  when  resizing  the  LDC 


ARSR-4  did  not  recover  from  a  short  term  power  loss  (<  5  sec) 


Some  target  reports  are  incorrectly  time  stamped 


COHO  status  alarm  was  not  reported  when  the  COHO  was  disabled 


FIT  aborted  due  to  scheduling  conflicts  when  ran  to  detect  a  disabled 


FIT  did  not  operate  correctly  with  a  fault  in  the  waveform  generator 


SP  cabinet  blower  alarms  #1  and  #2  are  reversed 


FIT  identified  a  single  fault  candidate  multiple  times  in  the  suspect  fault 


BIT  did  not  report  an  alarm  when  the  waveform  generator  was  faulted 


Pre-DRR 


Criticarrty 

Status 

SERIOUS 

Closed  (6/15/95) 

SERIOUS 

Closed  (6/15/95) 

SERIOUS 

Closed  (6/15/95) 

Moderate 

Closed  (11/11/94) 

SERIOUS 

Closed  (6/15/95) 

SERIOUS 

Closed  (7/6/95) 

SERIOUS 

Closed 

SERIOUS 

Closed  (6/28/95) 

SERIOUS 

Closed 

SERIOUS 

Closed  (6/15/95) 

SERIOUS 

Closed  (6/15/95) 

SERIOUS 

Closed  (6/28/95) 

SERIOUS 

SERIOUS 

Closed  (6/15/95) 

Moderate 

Open  (7/3/95) 

Moderate 

Closed  (7/14/95) 

Moderate 

Closed  (6/15/95) 

Moderate 

Closed 

Moderate 

Closed  (11/11/94) 

SERIOUS 

Closed  (6/28/95) 

Moderate 

Closed  (7/14/95) 

SERIOUS 

Closed  (6/28/95) 

Moderate 

Closed  (6/28/95) 

Minor 

Closed  (11/1 1/94) 

SERIOUS 

Closed  (6/15/95) 

SERIOUS 

Closed  (6/28/95) 

Minor 

Open 

SERIOUS 

Closed  -  See  TDR  151 

SERIOUS 

Closed  (7/14/95) 

Moderate 

Closed  (11/11/94) 

Moderate 

Closed 

Moderate 

Closed 

Minor 

Closed  (11/11/94) 

Minor 

Closed  (6/15/95) 

Moderate 

Closed 

Tabte  1 :  0T8,£  Test  Discf^ancy  Reports  (May  23, 1994  through  August  1, 

TOR# 

Date 

Descrqatian  of  TDR 

70 

8/30/94 

BIT/FIT  did  not  detect  or  isolate  a  map  control  failure 

71 

8/30/94 

FIT  did  not  isolate  a  frequency  select  board  failure 

72 

8/30/94 

BIT  did  not  detect  RRWDS  alarm  with  board  removed,  but  FIT  isolated 

73 

8/30/94 

BIT  did  not  detect  Rdr  Trig  alarm  with  board  removed,  but  FIT  isolated 

74 

8/30/94 

BIT  did  not  detect  STTG  alarm  with  board  removed,  but  FIT  isolated 

75a 

8/30/94 

BIT/FIT  did  not  detect/isolate  a  faulty  Preamp  Switch  In  the  Transmitter 

75b 

8/30/94 

BIT  did  not  detect  a  faulty  Preamp  switch,  but  FIT  Isolated  w/  TX  RF  ON 

75c 

8/30/94 

TX  automatically  shut  OFF,  FIT  could  not  isolate  faulty  Preamp  switch 

76 

9/1/94 

Excessive  time  to  report  an  alarm,  19  minutes  for  Det  Ch  1  Pulse 

77 

9/1/94 

Could  not  run  FIT  on  Det  CH  1  with  Pulse  Compressor  board  faulted 

78 

N/A 

N/A 

79 

9/7/94 

LDC  "PPl  Link  Down"  cleared  while  link  was  still  down  ,  no  link  alarms 

80 

9/7/94 

FIT  did  not  isolate  a  RDI  failure  with  RDI  board  removed,  FIT  showed 

81 

9/8/94 

Major  system  software  version  was  not  updated  from  the  28JUN94  ACCS 

82 

9/8/94 

Pedestal  Enclosure  ’B’  alarms  detected 

83 

9/9/94 

Placing  Drive  #1  disconnect  switch  In  the  'ON'  position  causes  warm  start 

84 

9/9/94 

Neither  drive  motor  would  start  with  a  single  APG  faulted 

85 

9/12/94 

Error  occurred  during  Data  Extraction,  resulting  in  a  stoppage 

86 

9/13/94 

A  hardware  extraction  type  101  resulted  In  a  warm  start  and  system  reset 

87 

9/13/94 

Hardware  extraction  type  101  &  102  resulted  in  GeoMap  HA’s 

88 

9/13/94 

Command  to  load  APG  offsets  resulted  in  an  error  message 

89 

9/15/94 

Drive  motor  #2  would  not  start  with  the  "Rotation  Interlock  Bypass"  switch 

90 

9/16/94 

TMDT  locked  up  after  removing  Loop  Controller  and  commanding  TX 

91 

9/16/94 

LNA  #8  damaged  due  to  a  failed  Pulse  Shape  Sequencer 

92 

9/16/94 

Search  loss  with  STC  end  range  change,  Srch  &  Ben  lost  with  STC  slope 

93 

10/5/94 

The  LDC  PPI/RAPPI  could  not  be  resized  to  the  default  display 

94 

10/5/94 

Beacon  video  becomes  offset  from  RAP  PI  by  3  degrees  clockwise 

95 

10/5/94 

Alarm  threshold  adjustments  were  required  when  LNA  #8  was  changed 

96 

10/5/94 

ARP  pulse  to  RRWDS  is  not  aligned  between  2  ACP  positive  pulses 

97 

10/5/94 

Commanding  sector  0  to  STAC  mode  caused  an  STC  HA,  cleared  in  VIP 

98 

10/5/94 

A  non-7700  military  emergency  target  is  not  processed  as  an  emergency 

99 

10/5/94 

CPU  #8  and  9  indicated  a  HA,  cold  start  restored  CPU  operation 

100 

10/5/94 

RMS  continuously  displays  HA  for  LDC  #2  SIO  port 

101 

10/6/94 

SRTQC  targets  are  not  output  after  switching  from  MAINT  to  OPER  mode 

102 

10/14/94 

ARSR-4  provides  no  indication  of  a  faulty  backup  battery 

Pre-DRR 


Critrcalrty 

Status 

Moderate 

Closed 

Moderate 

Closed 

Moderate 

Closed  (8/4/95) 

Moderate 

Open 

Moderate 

Closed 

Moderate 

Closed 

Moderate 

Closed 

Moderate 

Closed 

Moderate 

Closed 

Moderate 

Open 

Moderate 

Closed 

Moderate 

Closed 

SERIOUS 

Closed  (7/6/95) 

Moderate 

Closed  (1/4/95) 

SERIOUS 

Closed  (1/4/95) 

SERIOUS 

Open 

Minor 

Open  (7/3/95) 

SERIOUS 

Closed  (6/28/95) 

SERIOUS 

Closed  (6/28/95) 

Minor 

Closed  (6/28/95) 

Moderate 

S  Closed 

Moderate 

Open 

SERIOUS 

Open 

SERIOUS 

Closed  (7/3/95) 

Minor 

Open 

Moderate 

Open 

Moderate 

Open 

.sERioUs ; 

Open 

SERIOUS 

Closed  (7/3/95) 

SERIOUS 

Closed  (7/14/95) 

SERIOUS 

Open 

Minor 

Closed  (6/28/95) 

Moderate 

Closed  (7/3/95) 

SERIOUS 

Closed 

A-4 


Tgbte  i ;  0T5»£  Oiscrepanoy  Reports  (May  23, 1994  through  August  t99S) 


;  Dale 

103 

10/20/94 

104 

10/5/94 

105 

9/14/94 

106 

9/14/94 

107 

12/8/94 

108 

12/8/94 

109 

12/8/94 

110 

12/8/94 

111 

12/8/94 

112 

12/8/94 

113 

12/8/94 

114 

12/8/94 

115 

12/8/94. 

116 

12/8/94 

117 

12/8/94 

118 

12/8/94 

119 

12/8/94 

120 

12/11/94 

121 

12/11/94 

122 

12/11/94 

123 

12/11/94 

124 

3/1/95 

125 

3/1/95 

126 

3/1/95 

127 

3/1/95 

128 

3/1/95 

129 

3/24/95 

130 

3/24/95 

131 

3/24/95 

132 

3/24/95 

133 

3/24/95 

134 

4/26/95 

135 

4/26/95 

136 

4/26/95 

137 

4/26/95 

Oe$prpiqn  of  TOR 


Backup  battery  mounting  slot  is  misaligned 


Faulty  RRWDS  video  level  from  a  defective  RW  board  was  not  reported 


ARSR-4  does  not  meet  radar  range  and  azimuth  resolution  requirements 


Targets  are  not  resolved  when  separated  by  greater  than  minimum 
requirements 


Contiguous  Mode  3/A,  C  and  Mode  2,  C  targets  are  not  resolved 


RMS  menus  do  not  update  or  contain  missing  information 


Incorrect  target  readbacks  on  Menu  2.9.2  (Beacon  Operational  Test 
Targets) 


Weather  channel  status  incorrectly  reported  in  WXCHST  field 


Data  extraction  file  cannot  be  deleted  through  the  RMS  (Menu  7.1) 


False  SPl  indications  for  targets  with  the  FI  of  another  target  in  the  SPI 
position 


False  Emergency  Indication  on  the  LDC  with  a  Mode  2  of  7700 


ARSR-4  did  not  recover  from  a  short  term  power  loss  (<  15  seconds) 


Complete  loss  of  beacon  video  on  the  LDC,  channel  switch  required  to 
recover 


Cold  starts  exceed  the  1 80  second  requirement 


Automatic  fault  reset  did  not  work  for  alarms  5179  and  5279  (DSR/CTS 
Do'wn) 


With  PE  #1  set,  alarms  4288/4205  persist  and  synchronizer  ‘B’  switches  to 
UA-E 


PE  is  not  consistently  output  on  RAPPl,  8  or  more  hits  are  seen  in  detection 
video 


ARSR-4  sends  ‘Clear  Interface’  commands  on  the  ISM  interface  bus 


ARSR-4  requests  Ch  ‘A’  status  using  a  Ch  ‘B’  command  and  vice  versa 


lSM/ARSR-4  Interface  lockups  require  cable  removal  to  restore  interface 


BCOL  field  of  the  HOST  status  message  does  not  function 


Incorrect  beacon  altitudes  (Invalid  negative  altitudes) 


BRTQC  not  flagged  as  RTQC  and  reported  at  incorrect  range/azimuth 


Mode  S  status  message  fields  are  not  functioning 


Mode  S  ICD  and  TIBS  do  not  match 


Software  version  numbers  are  decrementing 


Short  Term  Power  Loss  Recovery 


Beacon  reports  offset  in  azimuth  by  thirty  degrees 


All  beacon  reports  aligned  along  one  azimuth 


Inability  to  switch  SIO  9  in  as  a  spare 


SIO  availability  /  alarm  reporting  anomalies 


Data  Loss/TX  turned  off  coincident  with  a  reported  CPU  Loss/Warm  start 


Warm  starts  while  attempting  Data  Extraction  Quick  Look 


Nine  second  data  loss  coincident  with  a  CPU  Loss/Warm  start 


Unable  to  bring  back  STBY  CPU  with  a  commanded  warm  start 


premn 


Cntica^ity 

-Status 

SERIOUS 

Closed  (12/15/94) 

Moderate 

Open 

Minor 

Open 

SERIOUS 

Open 

SERIOUS 

Closed  (6/28/95) 

SERIOUS 

Closed  (6/15/95) 

Moderate 

Closed  (6/28/95) 

SERIOUS 

Closed  (6/15/95) 

Minor 

Closed  (7/3/95) 

SERIOUS 

Closed  (7/14/95) 

Moderate 

1 _ 

Open 

Closed  -  See  TDR  151 

Moderate 

Closed  (7/14/95) 

Moderate 

Closed  (7/6/95) 

Moderate 

Closed  (6/28/95) 

Moderate 

Open 

Moderate 

Open 

Minor 

Closed  (7/6/95) 

Minor 

Closed  (7/6/95) 

SERIOUS 

Closed  (7/6/95) 

Open 

SERIOUS 

Closed  (7/6/95) 

SERIOUS 

Closed 

Moderate 

Open 

Moderate 

Open 

SERIOUS 

Closed  (7/6/95) 

.SERIOUS 

Closed  -  See  TDR  151 

SERIOUS 

Closed 

SERIOUS 

Open 

SERIOUS 

Closed  (6/28/95) 

SERIOUS 

Closed  (7/6/95) 

SERIOUS 

Closed  (7/21/95) 

SERIOUS 

Closed  (6/15/95) 

SERIOUS 

Closed  (7/21/95) 

Open 

Table  1 ;  OT&E  Test  Discrepancy  Reports  (May  23, 1994  through  August 


Tpfi# 

■pate 

Oescrpqn  of  TOft 

138 

4/26/95 

Consecutive  automatic  cold  starts  with  no  BIT  alarms  shown  on  RMS 

139 

4/26/95 

BRTQCA  bit  in  HOST  status  message  not  set  when  BRTQC  out  of 
tolerance 

140 

6/15/95 

Water  leaking  in  transmitter  room 

141 

6/15/95 

Water  found  in  2:1 :8  splitter  In  transmitter 

142 

6/15/95 

Frequency  Transition  hard  alarms  appearing  after  a  cold  start 

143 

6/15/95 

Multiple,  automatic  warm  starts 

144 

6/15/95 

Inconsistent  alarm  indications 

145 

6/15/95 

Incorrect  SRTQC  bit  operation  in  the  HOST  status  message 

146 

6/15/95 

ARSR-4  system  crashes  coincident  with  global  status  polling  on  MRS 
Interface 

147 

6/15/95 

Incorrect  M4AI_A  and  M4INOR  bit  operation  in  HOST  and  SOCC  status 
messages 

148 

6/15/95 

Incorrect  SPSTAT  bit  operation  in  SOCC  status  message 

149 

7/31/95 

Different  display  of  weather  on  DARC  vs.  NAS 

150 

7/31/95 

Inability  to  load  STC  for  one  sector  in  quadrants  2,  3,  or  4 

151 

7/31/95 

Summary  of  Power  Loss  TDRs 

152 

7/31/95 

Low  System  Reliability 

153 

7/31/95 

Low  System  Maintainability 

154 

7/31/95 

Lack  of  system  Configuration  Control 

Rre-^DRR 


Crttica^ity 


SERJPUS; 


SERtOUS 


SERtOUS 


SERJOUS 


SERIOUS  . 


SERJOUS 


SERIOUS 


SERIOUS 


Minor 


•SERtOUS 


Moderate 


SERIOUS 


SERiOUS 


SERJOUS 


SERtOUS 


Retest 


Open 


Open 


Open 


Open 


Closed  (6/28/95) 


Closed  (7/14/95) 
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IRES  PROGRAM  DESCRIPTIONS 


IRES  PROGRAM  DESCRIPTIONS 


This  appendix  contains  a  brief  description  of  the  IRES  programs  used  during  ARSR-4  OT&E. 
The  descriptions  were  extracted  from  IRES  user’s  manual.  A  more  detailed  description  of  the 
programs  can  be  found  in  the  user’s  manual. 


CmpDelay _ Compute  Report  Delay _ Analysis 

CmpDelay  computes  surveillance  report  delays  assuming  the  report  time  is  the  actual  time  output 
from  the  radar  system,  and  a  report  type  exists  that  has  zero  delay  (i.e.,  ASR-9  Sector  Marks). 


ColRB  Collimate  Radar/Beacon 


Analysis 


ColRB  produces  range,  azimuth  or  height  collimation  histograms.  The  collimation  histogram 
shows  the  frequency  of  position  differences  between: 

•  both  surveillance  types  (radar  and  beacon), 

•  one  surveillance  and  one  reference,  or 

•  both  reference  types  (to  establish  confidence  in  the  reference  used). 

Each  histogram  shows  the  mean  and  standard  deviation  of  position  difference. 


CopyLLA  Copy  Lat/Long/ Altitude  data  into  PCS  ■ 


Reformat 


CopyLLA  reformats  ASCII  Latitude,  Longitude,  and  Altitude  position  data  into  PCS-2  Reference 
reports,  performing  a  coordinate  transform  to  the  position  of  the  radar  antenna.  This  is  required 
before  merging  reference  data  with  the  tracked  reports  of  the  flight  test  aircraft.  The  coordinate 
transform  conforms  to  the  WGS-84  (NAD-83)  earth  model. 


CountPCS  Count  PCS  surveillance  reports 


Summary 


CountPCS  counts  the  number  of  each  type  of  surveillance  report  in  the  PCS  file.  For  radar 
reports  (RC  and  RO),  the  number  of  each  Quality  and  Confidence  pair  is  counted.  For  beacon 
reports  (RB  and  BO),  the  number  of  each  beacon  mode  (3/A,  2,  and  C)  validation  is  counted. 


CountTrk _ Count  TQA  qualified  reports 


Summary 


CountTrk  counts  the  number  of  each  surveillance  report  type  in  the  qualified  tracked  reports  file 
by  track  quality.  Also  counts  tracks  by  track  criteria.  The  track  qualities  are  assigned  by  Qualify. 
This  is  summary  step  in  the  Track  Quality  Assessment  (TQA)  process,  following  Track,  Qualify 
and  PlotTQA. 
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Delay _ Delay  Histograms _  Analysis 

Delay  plots  a  histogram  showing  the  distribution  of  surveillance  report  delays  relative  to  the 
boresight  of  the  radar  antenna.  The  recorded  file  must  contain  a  report  type  that  contains  antenna 
azimuth  at  time  of  recording.  ASR-9  sector  marks  or  artificial  sector  marks  (e.g.,  generated  by 
BEXR)  can  be  used.  The  Delay  histogram  bars  are  color  coded  by  report  type  (Radar,  Beacon, 
Correlated,  Reinforced). 


Filter _ Filter  PCS  surveillance  reports  _  Utility 


Filter  extracts  surveillance  reports  that  contain  (or  fail  to  contain)  the  values  entered  into  filter 
menus.  The  filter  menus  contains  a  range  of  values  for  the  fields  that  are  continuous  (e.g.,  range, 
azimuth,  time),  a  group  of  values  for  fields  that  have  a  list  of  values  (e  g..  Mode  3/A  codes)  or 
yes/no  (on/off)  switches  for  fields  that  are  enumerated  or  boolean  in  nature  (e  g..  Report  ID, 
Quality,  Confidence,  Code  Validation,  flags).  Filter  can  copy  the  reports  that  meet  the  filter  menus 
into  a  PASS  file  and/or  the  reports  that  do  not  meet  the  filter  into  a  FAIL  file. 


HgtAcc _ Height  Accuracy  Histograms _ _ Utility 

HgtAcc  produces  a  height  accuracy  versus  range  histogram  that  applies  a  barometric  altitude 
correction  to  the  beacon  altitude  before  comparing  with  primary  radar  height.  Two  altitude 
corrections  (  D  value)  define  a  line  from  the  beginning  to  the  end  of  a  track  and  a  linear 
interpolation  applies  corrections  at  any  range  along  the  track. 


MergePCS _ Merge  surveillance  and  reference  files  _  Utility 

MergePCS  consolidates  reference  reports  from  an  independent  high  precision  tracker  with 
selected  tracked  reports  from  the  radar  under  test.  This  is  used  when  an  independent  position 
source  (i.e.,  GPS,  Nike)  is  supplying  highly  accurate  positional  information  of  a  flight  test  aircraft. 


PlotElev _ Plot  Elevation  angle  versus  azimuth _ 

PlotElev  displays  an  elevation  versus  azimuth  plot  of  the  surveillance  reports. 


Utility 


PlotPCS 


Plot  PCS  surveillance  reports 


Utility 


PlotPCS  displays  a  PPI  plot  of  the  surveillance  reports  in  a  PCS  file.  You  may  "zoom  in"  to  look 
at  a  small  area  in  detail,  change  color  coding,  and  pause  and  clear  the  PPI  area. 
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PlotPD 


Percentage  of  Detection  Histogram 


Analysis 


PlotPD  displays  percentage  of  detection  histograms  of  a  single  test  aircraft.  The  histograms  show 
how  well  the  track  was  detected  from  zero  to  maximum  range  while  traveling  inbound  and 
outbound.  The  following  detection  histograms  are  available: 

•  Radar  Correlated  (RC)  reports  only, 

•  All  radar  reports  EXCEPT  Quality  0  Radar  Only  (RO)  reports, 

•  All  radar  reports  (RC,  RO,  and  Radar/Beacon), 

•  Beacon  reports  (RB,  and  Beacon  Only), 

•  Combined  Inbound/Outbound  Radar  and  Beacon  reports. 

The  histograms  may  be  shown  smoothed  over  three  range  bins  using  a  sliding  window  averaging 
process  where  the  detection  of  one  range  bin  is  influenced  by  the  detection  of  the  previous  and 
next  range  bin. 

PlotRes _ Plot  Resolution _ Analysis _ 

PlotRes  produces  a  resolution  histogram  of  the  radar  system.  To  determine  resolution,  truth  data 
is  used  to  determine  the  actual  separation  of  two  flight  test  aircraft.  The  presence  of  two  target 
reports  mean  the  two  aircraft  were  resolved,  while  one  report  means  the  two  aircraft  were  not 
resolved.  The  histogram  shows  how  often  the  both  aircraft  were  seen  and  at  what  separation.  An 
independent  reference  (i.e.,  GPS,  Nike)  position  yield  best  results. 

PlotRHI  Plot  Range  versus  Height  Indicator  Analysis 

PlotRHI  displays  an  Range  Height  Indicator  (RHI)  plot  of  beacon  Mode  C  altitude  or  radar  height 

versus  range. 

PlotScan _ Plot  Scan  summaries _ Utility _ 

PlotScan  displays  a  graph  of  the  number  of  report  (i.e.,  radar,  beacon,  RTQC,  Status,  etc.)  versus 
scan.  The  graph  shows  report  loading  over  time  and  can  be  used  to  identify  capacity  and  data 
dropout  problems. 


PlotTQA  Plot  TQA  tracks  Analysis 

PlotTQA  displays  PPI  plots  of  individual  target  of  opportunity  tracks.  This  is  the  third  step  in  the 
Track  Quality  Assessment  (TQA)  process,  following  Track  and  Qualify. 
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PlotWX 


Plot  Weather  Map  Utility 

PlotWX  displays  a  colored  PPI  plot  of  a  weather  map.  The  colors  show  the  weather  level 
contained  in  the  report.  The  meanings  of  the  levels  are  determined  by  the  radar  system  and  can  be 
made  consistent  by  PrepWx. 


PrepPCS _ Prepare  PCS-2  surveillance  reports _ Utility _ 

PrepPCS  prepares  a  PCS  surveillance  file  for  analysis  by  IRES  programs  by  placing  the  reports  in 
strict  range/azimuth  order  and  combining  multiple  reports  from  a  single  target  into  a  consolidated 
report  block.  Most  IRES  analysis  programs  require  the  output  of  PrepPCS,  display  only 
applications  do  not  require  this  step. 


PrepWx _ Prepare  PCS-2  weather  reports _ Utility _ 

PrepWx  prepares  a  PCS  weather  file  from  a  CD- 1/2  source  for  plotting  by  PlotWx  by  placing  the 
interlaced  weather  messages  in  azimuth  order  for  a  complete  map.  CD  weather  messages  are 
output: 

•  two  or  three  levels  per  weather  map, 

•  course  detail  or  fine  detail  (high  or  low  Interval) 

•  every  scan  or  alternating  scans  (Interlace), 

•  over  one,  two,  or  three  scans  for  each  level. 

A  complete  weather  map  requires  anywhere  from  2  scans  to  1 8  scans. 


Qualify _ Qualify  tracked  reports  _ Analysis 

Qualify  determines  the  track  quality  of  target  of  opportunity  tracks  using  up  to  26  true  and  false 
track  criteria  input  from  an  ASCII  file.  This  is  the  second  step  in  the  Track  Quality  Assessment 
(TQA)  process,  following  Track  and  preceding  PlotTQA. 


Record _ Record  CD  format  reports _ Data  Collection 

Record  provides  the  means  of  recording  CD  format  surveillance  and  weather  reports.  The 
program  reformats  the  CD  message  into  PCS-2  format  and  displays  the  reports  being  recorded  in 
a  PPI  plot. 
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RecRMS 


Records  RMS  screens 


Data  Collection 


RecRMS  is  a  terminal  emulator  for  the  local  Remote  Maintenance  System  terminal  connected  to 
the  radar  system.  It  allows  commands  to  the  RMS  to  be  captured  and  played  back  to  RMS  and  to 
capture  screens  from  RMS  in  pure  ASCII  form.  PC  cursor  keystrokes  generate  an  ANSI  escape 
sequence  to  send  to  RMS,  and  ANSI  escape  sequence  received  from  RMS  are  translated  for  the 
PC  display.  The  RMS  may  be  connected  directly  or  over  a  modem,  with  built-in  dialing  support. 


Select  Selective  Tracker 


Utility 


Select  tracks  one  or  two  flight  test  aircraft.  Mode  3/A  beacon  code(s)  are  used  to  initiate  track. 
Once  initiated,  the  tracking  algorithm  will  continue  update  the  predicted  position  using 
radar/beacon,  beacon  only  or  radar  only  reports. 


ShowPCS  Show  PCS  surveillance  reports 


Utility 


ShowPCS  displays  the  contents  of  PCS  surveillance  reports  in  an  easy  to  understand  fashion. 
Some  simple  searching  capabilities  are  built  in  to  help  you  find  specific  reports. 


ShowStat  Show  Status  contents 


Utility 


ShowStat  shows  the  contents  of  each  status  message  in  a  surveillance  report  file  along  with  the 
meaning  and  value  of  each  status  in  an  easy  to  understand  form.  A  pure  ASCII  status  definition 
file  contains  a  description  of  each  status  by  word,  bit  position  and  length,  a  mnemonic,  type,  and 
text  to  be  displayed  for  each  status  condition.  Any  pure  ASCII  text  editor  or  word  processor  can 
be  used  to  modify  the  status  definition  file. 


SortTrk _ Sort  Tracked  reports 


Utility 


SortTrk  ordered  tracked  reports  from  track  by  track  number,  putting  all  reports  of  a  track  in 
sequential  order.  This  is  part  of  the  Track  Quality  Assessment  (TQA)  Track  process  and  is 
automatically  started,  you  would  need  to  run  this  only  if  there  was  a  disk  problem  or  insufficient 
disk  space  to  perform  the  sorting. 


SplitCnt  Split  Count  summary 


Utility 


SplitCnt  counts  splits  in  three  ways:  the  number  of  reports  flagged  by  PrepPCS  as  splits,  the 
number  of  consolidated  report  blocks  containing  one  or  more  splits,  and  the  number  of 
consolidated  report  blocks  containing  a  beacon  report  and  one  or  more  splits. 
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Track 


Track  all  targets 


Utility 


Track  performs  an  alpha-beta  tracking  on  all  surveillance  reports  in  the  prepared  file.  Tracks  are 
initiated  on  any  eligible  radar  or  beacon  report,  and  updated  on  either  type  of  eligible  report. 
Report  eligibility  determines  whether  a  report  can  initiate  track,  or  update  a  track,  and  is 
controlled  by  menu  selection.  This  is  the  first  step  of  the  Track  Quality  Assessment  (TQA) 
process. 


B-6 


APPENDIX  C 


ARSR-4  AND  ARSR-3  QARS  RESULTS 


ARSR-4  AND  ARSR-3  QARS  RESULTS 


June  14,1995 

June  15,1995  | 

Parameter 

Fail 

ARSR-3 

ARSR-4 

ARSR-3 

ARSR-4 

Beacon 

Scans 

8798 

5915 

7844 

5957 

Blip/Scan 

<  96% 

99.1 

98.2 

98.5 

99.1 

Sch-Reinfor 

<  85% 

92.0 

95.2 

89.4 

94.3 

Az  Splits 

>.1% 

.0 

.2 

.0 

.2 

Rng  Splits 

>.1% 

.0 

.0 

.0 

.1 

Ring-Around 

>  .5% 

.0 

.0 

.0 

.0 

Reflections 

>  .2% 

.0 

.0 

.0 

.0 

Code  Zeroes 

>  .5% 

.0 

.1 

.0 

.0 

Mode  3/A  Rel 

<  98% 

99.5 

99.3 

99.5 

99.7 

Mode  3/A  Val 

<  98% 

99.1 

98.6 

99.2 

99.5 

Mode  C  Rel 

<  97% 

98.8 

99.2 

99.0 

99.5 

Mode  C  Val 

<  95% 

97.6 

'  97.2 

98.0 

98.4 

Mode  C  Scans 

8694 

5788 

7683 

5882 

Rng  Dev 

>0/1 

0/1 

0/1 

0/1 

0/1 

Az  Dev 

>2.0 

2.21 

1.89 

2.16 

1.88 

Log/Nml 

Scans 

917 

5915 

867 

5957 

Blip/Scan 

<  85% 

89.8 

93.8 

88.9 

93.9 

Az“Split 

>  .2% 

.0 

.2 

.0 

.1 

Rng-Split 

>3% 

.0 

.1 

.0 

.0 

PE  Verification 

#1  Rng  Error 

>0/1 

+0/0 

-0/1 

+0/0 

-0/1 

#1  Az  Error 

>2.0 

+1.2 

-0.1 

+0.8 

+0.1 

#1  Pet  Rel 

<  90% 

100.0 

100.0 

100.0 

100.0 

Total  Tracks 

99 

91 

91 

84 
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June  21.1995  | 

Parameter 

Fail 

ARSR-3 

ARSR-4 

ARSR-3 

ARSR-4 

Beacon 

Scans 

8656 

7233 

8610 

6224 

Blip/Scan 

<  96% 

99.1 

99.5 

98.8 

99.0 

Sch-Reinfor 

<  85% 

90,0 

96.6 

89.9 

98.0 

Az  Splits 

>.1% 

.0 

.2 

.0 

.0 

Rng  Splits 

>.1% 

.0 

.2 

.0 

.0 

Ring-Around 

>  .5% 

.0 

.0 

.0 

.0 

Reflections 

>  .2% 

.0 

.0 

.0 

.0 

Code  Zeroes 

>  .5% 

.0 

.0 

.0 

.1 

Mode  3/A  Rel 

<  98% 

99.4 

99.5 

99.6 

99.4 

Mode  3/A  Val 

<  98% 

99.1 

99.0 

99.2 

98.8 

Mode  C  Rel 

<  97% 

98.7 

99.4 

99.1 

99.1 

Mode  C  Val 

<  95% 

97.4 

98,1 

98.1 

97.8 

Mode  C  Scans 

8525 

7181 

8454 

6100 

Rng  Dev 

>0/1 

0/1 

0/1 

0/1 

0/0 

Az  Dev 

>2.0 

2.11 

1.77 

2.00 

1.68 

Log/Nml 

Scans 

787 

7233 

764 

6224 

Blip/Scan 

<  85% 

85.8 

96.4 

88.2 

97.3 

Az-Split 

>  .2% 

.0 

.1 

.0 

.1 

Rng-Split 

>3% 

.0 

.0 

.0 

.0 

PE  Verification 

#1  Rng  Error 

>0/1 

+0/0 

-0/1 

+0/0 

-0/1 

#1  Az  Error 

>2.0 

-0.7 

-0.1 

-0.9 

-0.3 

#1  Pet  Rel 

<  90% 

98.0 

100.0 

100.0 

100.0 

Total  Tracks 

105 

106 

105 

88 
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June22J995 

June  23,1995  I 

Parameter 

Fail 

ARSR-3 

ARSR-4 

ARSR-3 

ARSR-4 

Beacon 

Scans 

8237 

5474 

7638 

5697 

Blip/Scan 

<  96% 

99.1 

99.4 

99.4 

99.7 

Sch-Reinfor 

<  85% 

91.6 

98.2 

92.3 

97.8 

Az  Splits 

>.1% 

.0 

.0 

.0 

.0 

Rng  Splits 

>.1% 

.0 

.0 

.0 

.0 

Ring-Around 

>  .5% 

.0 

.0 

.0 

.0 

Reflections 

>  .2% 

.0 

.0 

.0 

.0 

Code  Zeroes 

>  .5% 

.0 

.0 

.0 

.1 

Mode  3/A  Rel 

<  98% 

99.7 

99.2 

99.9 

99.3 

Mode  3/A  Val 

<  98% 

99.3 

98.7 

99.6 

98.9 

Mode  C  Rel 

<  97% 

99.3 

98.8 

99.4 

99.1 

Mode  C  Val 

<  95% 

98.3 

97.0 

98.7 

98.0 

Mode  C  Scans 

8109 

5413 

7572 

5636 

Rng  Dev 

>0/1 

0/1 

0/0 

0/1 

0/1 

Az  Dev 

>2.0 

2.05 

1.73 

2.07 

1.73 

Log/Nml 

Scans 

862 

5474 

1097 

5697 

Blip/Scan 

<  85% 

88.9 

97.9 

90.8 

97.7 

Az-Split 

>  .2% 

.0 

.1 

.0 

.1 

Rng-Split 

>3% 

.0 

.0 

.0 

.0 

PE  Verification 

#1  Rng  Error 

>0/1 

+0/0 

-0/1 

+0/0 

-0/1 

#1  Az  Error 

>2.0 

-0.4 

-0.1 

-0.1 

-0.3 

#1  Pet  Rel 

<  90% 

100.0 

96.0 

98.0 

98.0 

Total  Tracks 

103 

88 

108 

92 
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June  27,1995  | 

Parameter 

Fall 

ARSRr3  ^ 

ARSR-4 

ARSR-3 

ARSR-4 

Beacon 

Scans 

9050 

6643 

8267 

6407 

Blip/Scan 

<  96% 

98.9 

99.6 

99.5 

99.6 

Sch-Reinfor 

<  85% 

91.4 

97.6 

92.8 

97.0 

Az  Splits 

>.1% 

.0 

.0 

.0 

.1 

Rng  Splits 

>.1% 

.0 

.0 

.0 

.0 

Ring-Around 

>  .5% 

.0 

.0 

.0 

.0 

Reflections 

>  .2% 

.0 

.0 

.0 

.0 

Code  Zeroes 

>  .5% 

.0 

.2 

.0 

.1 

Mode  3/A  Rel 

<  98% 

99.5 

99.0 

99.7 

99.6 

Mode  3/A  Val 

<  98% 

98.9 

98.3 

99.3 

99.3 

Mode  C  Rel 

<  97% 

98.8 

98.8 

99.2 

99.4 

Mode  C  Val 

<  95% 

97.8 

97.4 

98.1 

98.3 

Mode  C  Scans 

8909 

6552 

8225 

6378 

Rng  Dev 

>0/1 

0/1 

0/1 

0/1 

0/0 

AzDev 

>2.0 

2.02 

1.79 

1.97 

1.71 

Log/'Nml 

Scans 

1021 

6643 

964 

6407 

Blip/Scan 

<  85% 

86.4 

97.3 

91.3 

96.6 

Az-Split 

>  .2% 

.0 

.1 

.0 

.2 

Rng-Split 

>3% 

.0 

.1 

.0 

.1 

PE  Verification 

#1  Rng  Error 

>0/1 

+0/0 

-0/1 

+0/0 

-0/1 

#1  Az  Error 

>2.0 

-0.1 

-0.2 

+0.1 

+0.0 

#1  Pet  Rel 

<  90% 

100.0 

100.0 

100.0 

98.0 

Total  Tracks 

100 

94 

89 

90 

C-5 


June  28,1995 


June  29.1995 


Beacon 
Scans 
Blip/Scan 
Sch-Reinfor 
Az  Splits 
Rng  Splits 
Ring-Around 
Reflections 
Code  Zeroes 
Mode  3/A  Rel 
Mode  3/A  Val 
Mode  C  Rel 
Mode  C  Val 
Mode  C  Scans 
Rng  Dev 
Az  Dev 
Log/Nml 
Scans 
Blip/Scan 
Az-Split 
Rng-Split 
PE  Verification 
#1  Rng  Error 
#1  Az  Error 
n  Pet  Rel 
Total  Tracks 


<  96% 

<  85% 
>.1% 
>.1% 

>  .5% 

>  ,2% 
>  .5% 

<  98% 

<  98% 

<  97% 

<  95% 

>0/1 

>2.0 


<  85% 
>  .2% 
>3% 


ARSR-3 


8557 

98.6 
89.4 

.0 

.0 

.0 

.0 

.0 

99.6 
99.1 

98.8 

97.8 
8412 
0/1 
2.04 

916 

82.8 
.0 
.0 

+0/0 

+0.3 

98.0 

107 


ARSR-4 


7286 

98.8 

96.8 
.1 
.0 
.0 
.0 
.2 

99.3 

98.8 
99.1 
97.7 
7186 
0/1 
1.78 

7286 

96.3 

.1 

.1 

-0/1 

+0.4 

96.0 

105 


ARSR-3 


7702 

99.0 

89.5 

.0 

.0 

.0 

.0 

.0 

99.4 
98.9 
98.8 

97.5 
7597 
0/1 
1.98 

697 

82.3 

.0 

.0 

+0/0 

-0.4 

100.0 

87 


ARSR-4 


5741 

99.0 

96.7 

.0 

.0 

.0 

.0 

.1 

99.4 

98.9 

99.2 
97.6 
5661 
0/0 
1.79 

5741 

96.2 
.0 
.0 

-0/1 

-0.0 

100.0 

83 


>0/1 
>2.0 
<  90% 


July  07. 1995 

July  10  J  995  1 

Parameter 

Fail 

ARSR-3 

ARSR-4 

ARSR-3 

ARSR-4 

Beacon 

Scans 

8003 

6010 

9228 

6386 

Blip/Scan 

<  96% 

98.2 

98.6 

98.9 

99.4 

Sch-Reinfor 

<  85% 

88.1 

95.1 

91.1 

96.0 

Az  Splits 

>.1% 

.0 

.2 

.0 

.3 

Rng  Splits 

>.1% 

.0 

.1 

.2 

.3 

Ring-Around 

>  .5% 

.0 

.0 

.0 

.0 

Reflections 

>  .2% 

.0 

.0 

.0 

.0 

Code  Zeroes 

>  .5% 

.0 

.1 

.0 

.1 

Mode  3/A  Rel 

<  98% 

99.6 

99.4 

99.5 

99.2 

Mode  3/A  Val 

<  98% 

98.8 

98.3 

98.7 

98.2 

Mode  C  Rel 

<  97% 

98.5 

98.8 

98.4 

98.8 

Mode  C  Val 

<  95% 

97.0 

96.8 

97.0 

97.2 

Mode  C  Scans 

7779 

5824 

9026 

6258 

Rng  Dev 

>0/1 

0/1 

0/1 

0/1 

0/1 

Az  Dev 

>2.0 

2.00 

1.75 

2.05 

1.81 

Log/Nml 

Scans 

691 

6010 

925 

6386 

Blip/Scan 

<  85% 

78.5 

94.3 

85.7 

95.6 

Az-Split 

>  .2% 

.0 

.0 

.0 

.2 

Rng-Split 

>3% 

.0 

.0 

.0 

1  .1 

PE  Verification 

#1  Rng  Error 

>0/1 

+0/0 

-0/1 

+0/0 

-0/1 

#1  Az  Error 

>2.0 

+0.1 

-0.1 

+0.0 

+0.0 

m  Pet  Rel 

<  90% 

100.0 

98.0 

98.0 

96.0 

Total  Tracks 

101 

93 

105 

100 

C-7 


July  13,1995 

Julyl8.1995  | 

Parameter 

Fail 

ARSR-3 

ARSR-4 

ARSR-3 

ARSR-4 

Beacon 

Scans 

9413 

7861 

7252 

6563 

Blip/Scan 

<  96% 

98.7 

99.3 

99.2 

99.4 

Sch-Reinfor 

<  85% 

91.2 

96.8 

89.9 

97.3 

Az  Splits 

>.1% 

.0 

.2 

.0 

.1 

Rng  Splits 

>.1% 

.0 

.1 

.0 

.0 

Ring-Around 

>  .5% 

.0 

.0 

.0 

.0 

Reflections 

>  .2% 

.0 

.0 

.0 

.0 

Code  Zeroes 

>  .5% 

,0 

.1 

.0 

.0 

Mode  3/A  Rel 

<  98% 

99.1 

99.4 

99.5 

99.4 

Mode  3/A  Val 

<  98% 

98.5 

98.7 

99.3 

98.9 

Mode  C  Rel 

<  97% 

98.5 

99.1 

98.8 

99.0 

Mode  C  Val 

<  95% 

97.2 

97.4 

97.8 

97.6 

Mode  C  Scans 

9231 

7764 

7121 

6453 

Rng  Dev 

>0/1 

0/1 

0/0 

0/1 

0/1 

Az  Dev 

>2.0 

1.95 

1.78 

2.08 

1.79 

Log/Nml 

Scans 

934 

7861 

688 

6563 

Blip/Scan 

<  85% 

80.6 

96.6 

85.3 

97.0 

Az-Split 

>  .2% 

.0 

.1 

.0 

.2 

Rng-Split 

PE  Verification 

>3% 

.1 

.1 

.0 

.1 

#1  Rng  Error 

>0/1 

+0/0 

-0/1 

+0/0 

-0/1 

#1  Az  Error 

>2.0 

-0.5 

-0.2 

+0.1 

-0.2 

#1  Pet  Rel 

<  90% 

94.0 

96.0 

100.0 

100.0 

Total  Tracks 

113 

113 

94 

95 

C-9 


July  26  J  995 


Parameter 

Fail 

ARSR-3 

ARSR-4 

ARSR-3 

ARSR-4 

Beacon 

Scans 

7874 

6103 

7924 

5230 

Blip/Scan 

<  96% 

99.0 

99.5 

99.2 

99.7 

Sch-Reinfor 

<  85% 

90.0 

98.1 

87.5 

96.5 

Az  Splits 

>.1% 

.0 

.2 

Rng  Splits 

>.1% 

.0 

.0 

.0 

.1 

Ring-Around 

>  .5% 

.0 

.0 

Reflections 

>  .2% 

.0 

.0 

.0 

.0 

Code  Zeroes 

>  .5% 

1.1 

.0 

.1 

Mode  3/A  Rel 

<  98% 

99.7 

99.5 

99.4 

99.4 

Mode  3/A  Val 

<  98% 

99.2 

99.1 

Mode  C  Rel 

<  97% 

98.9 

99.3 

99.0 

99.4 

Mode  C  Val 

<  95% 

98.1 

98.2 

97.6 

97.3 

Mode  C  Scans 

7668 

6068 

7842 

5192 

Rng  Dev 

>0/1 

0/1 

0/0 

0/1 

Az  Dev 

>2.0 

2.09 

1.70 

2.05 

1.69 

Log/Nml 

Scans 

816 

779 

5230 

Blip/Scan 

<  85% 

85.7 

81.8 

96.4 

Az-Split 

>  .2% 

.0 

.1 

.0 

.3 

Rng-Split 

>3% 

.0 

.1 

.0 

PE  Verification 

#1  Rng  Error 

>0/1 

+0/0 

-0/1 

+0/0 

-0/1 

#1  Az  Error 

>2.0 

+0.2 

-0.2 

-0.2 

#1  Pet  Rel 

<  90% 

98.0 

100.0 

100.0 

100.0 

Total  Tracks 

94 

84 

83 

76 

July  31,1995 


C-11 


August 

L  1995 

August 

2,  1995 

Parameter 

Fail 

ARSR-3 

ARSR-4 

ARSR-3 

ARSR- 

Beacon 

Scans 

8136 

5296 

8201 

4856 

Blip/Scan 

<  96% 

99.3 

99.7 

99.5 

99.4 

Sch-Reinfor 

<  85% 

88.5 

97.1 

87.6 

97.0 

Az  Splits 

>.1% 

.0 

.1 

.0 

.3 

Rng  Splits 

>.1% 

.0 

.0 

.0 

.1 

Ring-Around 

>  .5% 

.0 

.0 

.0 

.0 

Reflections 

>  .2% 

.0 

.0 

.0 

.0 

Code  Zeroes 

>  .5% 

.0 

.1 

.0 

.3 

Mode  3/A  Rel 

<  98% 

99.7 

99.6 

99.4 

99.3 

Mode  3/A  Val 

<  98% 

99.2 

99.2 

99.0 

98,8 

Mode  C  Rel 

<  97% 

99.1 

99.4 

98.9 

99.0 

Mode  C  Val 

<  95% 

98.2 

98.1 

98.2 

97.6 

Mode  C  Scans 

8066 

5260 

8157 

4816 

Rng  Dev 

>0/1 

0/1 

0/1 

0/1 

0/0 

Az  Dev 

>2.0 

2.00 

1.70 

2.07 

1.79 

Log/Nml 

Scans 

928 

5296 

1106 

4856 

Blip/Scan 

<  85% 

83.0 

97.0 

76.9 

96.6 

Az-Split 

>  .2% 

.0 

.2 

.0 

.3 

Rng-Split 

>  3% 

.1 

.0 

.0 

.0 

PE  Verification 

#1  Rng  Error 

>0/1 

+0/0 

-0/1 

+0/0 

-0/1 

#1  Az  Error 

>2.0 

-0.0 

-0.1 

+0.3 

+0.0 

n  Pet  Rel 

<  90% 

98.0 

98.0 

100.0 

100.0 

Total  Tracks 

88 

79 

94 

81 

C-12 


August 

3,  1995 

August 

4.  1995 

Parameter 

Fail 

ARSR-3 

ARSR-4 

ARSR-3 

ARSR-4 

Beacon 

Scans 

8166 

5054 

8266 

5293 

Blip/Scan 

<  96% 

99.1 

99.1 

99.0 

98.7 

Sch-Reinfor 

<  85% 

89.3 

96.2 

87.6 

94.8 

Az  Splits 

>.]% 

.0 

,1 

.0 

.1 

Rng  Splits 

>.1% 

.0 

.1 

.0 

.0 

Ring-Around 

>  .5% 

.0 

.0 

.0 

.0 

Reflections 

>  .2% 

.0 

.0 

.0 

.0 

Code  Zeroes 

>  .5% 

.0 

.1 

.0 

.1 

Mode  3/A  Rel 

<  98% 

99.7 

99.5 

99.4 

99.5 

Mode  3/A  Val 

<  98% 

99.5 

99.1 

99.1 

98.6 

Mode  C  Rel 

<  97% 

99.5 

99.1 

99.0 

99.3 

Mode  C  Val 

<  95% 

98.6 

98.4 

97.9 

97.5 

Mode  C  Scans 

8030 

4962 

8126 

5178 

Rng  Dev 

>0/1 

0/1 

0/0 

0/1 

0/1 

Az  Dev 

>2.0 

2.02 

1,77 

1.98 

1.78 

Log/Nml 

5293  . 

Scans 

857 

5054 

857 

Blip/Scan 

<  85% 

85.2 

95.5 

80.7 

94.2 

Az-Split 

>  .2% 

.0 

.1 

.0 

.2 

Rng-Split 

>3% 

.1 

.0 

.0 

.0 

PE  Verification 

#1  Rng  Error 

>0/1 

+0/0 

-0/1 

+0/0 

-0/1 

#1  Az  Error 

>2,0 

-0.4 

-0.0 

-0.4  • 

+0.1 

#1  Pet  Rel 

<  90% 

98.0 

98.0 

100.0 

100.0 

Total  Tracks 

85 

78 

88 

86 

C-13 


Parameter 

Fail 

ARSR-^3 

ARSR-4 

Beacon 

Scans 

8313 

5928 

Blip/Scan 

<  96% 

99.1 

99.5 

Sch-Reinfor 

<  85% 

90.0 

96.8 

Az  Splits 

>.1% 

.0 

.2 

Rng  Splits 

>.1% 

.0 

.1 

Ring-Around 

>  .5% 

.0 

.0 

Reflections 

>  .2% 

.0 

.0 

Code  Zeroes 

>  .5% 

.0 

.2 

Mode  3/A  Rel 

<  98% 

99.5 

99.2 

Mode  3/A  Val 

<  98% 

99.1 

98.3 

Mode  C  Rel 

<  97% 

99.2 

98.9 

Mode  C  Val 

<  95% 

98.1 

97.3 

Mode  C  Scans 

8201 

5858 

Rng  Dev 

>0/1 

0/1 

0/1 

Az  Dev 

>2.0 

2.02 

1.74 

Log/Nml 

Scans 

539 

5928 

Blip/Scan 

<  85% 

89.4 

96.6 

Az-Split 

>  .2% 

.0 

.0 

Rng-Split 

>3% 

.0 

.0 

PE  Verification 

#1  Rng  Error 

>0/1 

+0/0 

-0/1 

#1  Az  Error 

>2.0 

-0.1 

-0.1 

#1  Pet  Rel 

<  90% 

100.0 

100.0 

Total  Tracks 

93 

88 

APPENDIX  D 


OPERATIONAL  TEST  QUESTIONNAIRES 


OPERATIONAL  TEST  QUESTIONNAIRES 


Questionnaires  were  developed  to  obtain  input  from  air  traffic  controllers  concerning  the 
suitability  and  effectiveness  of  the  ARSR-4  operating  in  NAS.  Controllers  participated  in  the 
development  of  the  questionnaires  as  well  as  responding  to  the  questions.  This  appendix  lists  the 
questions  and  corresponding  controller  responses.  Controller  Yes,  No,  or  Not  Observed, 
responses  to  each  question  are  included  along  with  any  additional  comments.  The  unshaded 
portions  of  the  tables  correspond  to  responses  from  precertification  tests  and  the  shaded  portions 
from  postcertification  tests. 


Does  the  ARSR  4/ARTCC  interface  provide  the  following? 

1 .  The  capability  to  identify,  track  and  control  aircraft  in  your  sector  or  surveillance  area? 


Yi  No  :  :  ■ 

Comments 

A 

X 

B 

X 

c 

X 

D 

X 

E 

X 

F 

X 

G 

m&m 

H 

I 

iMil 

F 

iiiiiii 

J 

ilBii 

K 

■fcl 

L 

M 

N 

iiiil 

0 

iiliii 

F 

X 

Q 

X 

M 

X 

R 

X 

D-1 


2.  Observable  information  on  the  controller  displays?  FDB/LDB,  MODE  C? 


No 

Not  Observ^ed 

Comments 

A 

X 

B 

X 

c 

X 

D 

X 

E 

X 

F 

X 

G 

X 

ailiiiiiiiiiil 

X 

I 

X 

F 

•  1  • 

X 

X' 

L  . 

X 

s:-  I:.:.  :*  M  "■ 

X 

N 

■aX  . 

F 

iiiiii 

.  Q 

ilBIl 

ivr,. 

Iiiiii 

V  R  '• 

liiBiiii 

3.  The  display  of  weather  information? 


'?Yes.  v 

No  ; 

^  N 

Comments 

A 

X 

B 

X 

c 

X 

D 

X 

E 

X 

F 

X 

G 

X 

H 

iililiifc 

I 

X 

Some  false  ^veather 

•.  F  ■■ 

■  J 

K  ■ 

X 

L 

M  ... 

X  . 

Erroneous 

N 

.0  .  . 

■  'F' 

Q 

iiiiii 

M 

iiiiii 

R 

iiiiii 

Erroneous 

D-2 


4.  The  capability  to  allow  you  to  provide  required  air  traffic  services? 


D-3 


6.  Aircraft  in  Coast  Track? 


GonlroUer 

■■■■yes  ■ 

No 

i  Not  Observed 

Comments 

A 

X 

B 

X 

c 

X 

D 

X 

E 

X 

F 

X 

■■ 

■"X.' 

H 

X 

I 

X 

F 

X 

J 

X 

K 

X 

vand)'!  i  %  approx  16 1 5z  over 

jki  went  into  coast  track 

L 

X 

M 

X  : 

N 

X 

•.X 

P 

X 

Q 

M  ■ 

X...  ' 

R 

X 

7.  Did  areas  of  known  poor  Radar  coverage  improve  with  the  ARSR-4  system? 


D-4 


8.  Did  you  observe  limited  data  blocks  and  full  data  blocks  in  areas  and  at  times  you  should  have? 


Controller 

i'-Yes/ 

1^  , 

Observed 

Comments 

A 

X 

B 

X 

C 

X 

D 

X 

E 

X 

F 

X 

•  ■  ■  0  ■ 

mmmm 

H 

iiiiiiii 

..j....  .... 

iiiii 

■  ...p  , 

iiiiii 

1 

Iiiiiiii 

K 

X  ■' 

vaiwh'li  @  approx  16I5z  over 

Iji  went  into  a  coast  track 

L 

X 

M 

iiiiii 

N 

iiiiii 

O 

iittli 

F 

iiiiiiii 

■  •  ‘=--*  '•  ■■■••  ;■ 

r'^..  Q  '■(  ■■ 

iiiiiiii 

:  ■  M  V' 

■Iiiii 

iiiiiiii 

PRIMARY  RADAR  COVERAGE 


1.  Did  you  observe  targets  in  all  4  quadrants  of  the  radar  coverage  envelope  (360  degrees)? 


Controller 

Yes 

No 

Not  Observed 

Comments 

G 

■X. 

H 

'J'  X 

1 

X 

I 

X 

K 

....  .vs-^  ..:N 

0 

.  X  1  i':'  |  ;  vS ‘ '' 

Q 

X 

X 

R 

•••X  iv 

D-5 


2.  Did  you  observe  targets  at  ditferent  ranges  (5-250  NM)  from  the  radar  site? 


Controller 

Q 

:■  H 

iiiiiiiili 

.  F 

iiiiiiili 

K  ' 

■ipL  ■  ■ 

M 
?•••:•  '  N 

o 

-p  : 

Q 

'  I:  M  "  ■ 

■R 


Yes  No 


Not  Observed 


Comments 


Range  set  @  75  NM 
Range  restricted 


RSB  Limitations 


3.  Did  you  observe  altitude  readout  information  at  varying  heights  (up  to  100,000  feet  or  the 
maximum  altitude  capability  of  the  test  aircraft)  throughout  the  coverage  area? 


Controller 


:  G 
H 

F 

^  :'4  V 
■:'XrK  X: 


Yes  No 


Not  Observed 


Comments 


Alt  Uffiit  000-242 


Altitude  restricted 


Altitude  Limitations 


4.  Did  you  observe  any  holes  (loss  of  target  areas)  in  the  radar  coverage  area? 


Controller 

Yes 

No 

Not  Observ'ed 

Comments 

.  G 

.  ... 

H 

X 

I 

X 

F 

i 

K 

■■■viC:  ■. 

•1'  1:- 

M 

'  'X  ’ 

wedge 

N 

;:x" 

0 

X  • 

p 

. X  \ Hi 

X 

M 

X  . 

;'v  -R 

X 

5.  How  does  the  radar  coverage  of  the  ARSR-4  compare  to  the  radar  coverage  that  was  replaced 
by  the  ARSR-4? 


Controller 

Yes 

No 

Not  Observed 

Comments 

.G  >i. 

X  . 

m  :p:;: 

X 

X 

X  ■ 

.  .J 

X 

X  ^ 

About  die  same  coverage 

Xv‘ 

x.--;; 

M 

X 

..  .JsJ 

X  ■ 

0 

X 

F 

Q 

M 

D-7 


PRIMARY  RADAR  TARGET  DETECTION 

1 .  Did  you  observe  primary  targets  of  varying  speeds  at  different  altitude  and  ranges  in  the  areas 
listed  below? 


a.  Clear  Areas  (No  Clutter) 


Controller 

Yes 

No 

Not  Observed 

Comments 

G 

X 

H 

X 

I 

X 

X 

X 

K 

X 

L 

X 

'  M 

X 

N 

X 

0 

■  X 

F 

X 

'■■W  ■■ 

■■  ■  ■  M 

x" 

Altitudes  unknown 

■•••■  R 

X 

b.  Clutter  areas  (sea,  terrain,  precipitation) 


Controller 

Yes 

No 

Not  Observed 

Comments 

G 

X 

H 

•  •• 

■  X 

I  • 

F 

1 

K 

L 

M 

X 

N 

X 

•  0  " 

X 

P 

X 

Q  .. 

X 

M 

X  ■ 

AlUludes  unknown 

R 

X 

D-8 


2.  Could  you  track  primary  targets  through  areas  of  clutter? 


Controller 

:  Yes 

■SSI 

Not  Observed 

Comments 

G 

H 

‘X 

I 

X 

F 

X 

1 

.  K 

Didn't  have  the  opportanity 

L 

X 

M 

'■'■'X  ■■■■ 

N 

X 

0 

X 

Jii  .  P 

X 

Q 

:  ■■ : : !  ! '• . !  X  ^ ' xx j-  ;X;: ; •  ’ 

M 

•  R 

3.  Did  you  observe  primary  targets  of  different  sizes  at  different  altitudes  and  ranges  in  the  areas 
listed  below? 


a.  Clear 


Controller 

Yes 

No 

Not  Observed 

Comments 

G 

X  ■ 

I 

X 

F 

J 

^  K  ■ 

. 

M 

'[■X 

'  -.-N-  ■'•'C . 

'  W 'A '-'iM-'.. 

X 

X 

M  •' 

X  . 

Altitades  ankoows 

R 
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PRIMARY  RADAR  FALSE  ALARM  RATE 


1 .  Did  you  observe  the  presence  of  false  targets? 


Yes 

No 

Not  Observed 

Comments 

A 

X 

B 

X 

c 

X 

D 

X 

E 

X 

F 

X 

G 

X 

■  ■;«  L 

X 

i;:"  .  V  .  ■  ■:  ■■■'•■  ' 

F  ' 

■  ■  .  i 

A  ' 

X 

1 

■III 

K 

X 

L 

M  • 

■,'::X 

N 

X 

O 

luiij 

X 

P 

llrStvv -X,- . .. 

Q 

X 

2.  Could  you  differentiate  false  targets  from  real  targets? 


Controller 

Yes 

No 

Not  Observed 

Comments 

A 

X 

B 

X 

C 

X 

D 

X 

E 

X 

F 

X 

G 

X  ■  ■ 

H  ; 

v"  X  ■■ 

I 

X 

F 

:  .  X 

1 

X 

K 

X 

L 

■  '  X  . 

M 

X 

N 

X 

O 

X 

P 

X 

X 

■  .  X 

R 

X 
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3.  Could  you  determine  what  the  false  target  was  reflected  from? 


Yes 

No 

Not  Obsen^ed 

CoiTunents 

A 

X 

B 

X 

C 

X 

D 

X 

E 

X 

F 

X 

.  G 

X 

H 

.  X 

I 

X 

•liiliiM 

X 

1 

K 

lllllll 

":.L 

M 

X 

N  ■' 

■  •  ■  X 

0  -: 

:  '  X" 

P  ■ 

X 

Q 

X 

.  M 

X 

"'\x"  \ 

Sometimes 
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5.  Do  these  false  targets  have  an  adverse  effect  on  the  following: 
a.  Tracking  a  primary  target? 


Controller 

-Yes 

Not  Observed  : 

Gomments 

A 

X 

B 

X 

c 

X 

D 

X 

E 

X 

F 

X 

i..  •...iE; 

X 

X 

I 

X 

^  • 

X 

1 

X 

K 

■  X  ■ 

L 

X 

M  ’ 

X 

li? 

O 

X 

P 

X  ■ 

Q 

■'  X 

•  M 

X  '■ 

b.  Identifying  a  primary  target? 


Controller 

Yes. 

No 

Not  Observed 

Comments 

A 

X 

B 

X 

C 

X 

D 

X 

E 

X 

F 

X 

G 

X 

H 

X 

1 

X 

E  • 

X 

} 

x;- 

K 

X 

L 

X  ■ 

■  M  ■■■■■ 

X 

N  \ 

X 

O 

X 

F 

] 

X 

Q 

X 

1  R _ _ 

X 
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c.  Providing  traffic  advisories? 


D-14 


6.  Could  you  recognize  false  targets  caused  by  terrain  and  sea  clutter? 


D-15 


8.  Could  you  recognize  false  targets  caused  by  distributed  precipitation? 
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PRIMARY  RADAR  ACCURACY 


Did  the  ARSR-4  provide  the  information  needed  for  the  following: 


1 .  To  adequately  separate  two  aircraft? 


2.  Radar  vectoring? 


D-17 


3.  To  determine  when  an  aircraft  was  clear  of  an  obstruction? 


Controller 

Yes 

Mo:;;: 

Comments 

A 

X 

B 

X 

c 

X 

D 

X 

E 

X 

F 

X 

M 

.  ■•••• -  I 

•  F 

1 

K  ■  ■  ■  . 

•  ^  ; 

1 

M.  . 

ilMi 

H 

o. 

F 

’  '  ■  * . ,,  V*  *x*‘  • 

Q  . 

■■  X-- 

X  1 

R 

X  I 

4.  To  observe  a  target  coincidental  with  the  aircraft's  known  position? 


wMb-;;;: 

Not  Observed 

Comments 

A 

X 

B 

X 

C 

X 

D 

X 

E 

X 

F 

X 

F 

X 

1 

K 

X 

L 

M 

iWli 

N 

0 

F 

Q 

M 

R 

X 

D-18 


6.  To  determine  target  degradation  in  the  presence  of  clutter? 


^;Yes.-' 

Comments^  ^ 

A 

X 

Don't  know  what  this  means 

B 

X 

c 

X 

D 

X 

E 

X 

F 

X 

Q 

X 

H 

X 

I 

X 

r 

j 

X 

K 

X 

L 

iliiiiiiiliiiM 

U 

X 

N 

0 

X  ; 

p 

•  X  ■ 

Q 

M 

X 

R 

X 
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7.  Provide  for  the  control  and  separation  of  air  traffic? 


RANGE  AND  AZIMUTH  RESOLUTION 


1.  From  the  demonstration,  could  you  distinguish  between  two  beacon  targets  that  were  at  the 
same  azimuth  and  separated  by  5  nm? 


Controller 

cYes 

No  : 

Not  Observed 

Comments 

A 

X 

B 

X 

C  , 

X 

D 

X 

E 

X 

F 

X 

2.  Did  you  observe  any  beacon  code  or  data  block  swapping? 


Controller 

Yes 

No 

Not  Observed 

Comments 

A 

B 

C 

D 

E 

X 

F 

X 
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3.  What  was  the  closest  distance  observed  between  two  beacon  targets  (AT  DIFFERENT 
ALTITUDES)  at  the  same  range  before  they  merge? 


Controller 

^  Yes--: 

Gonunehts 

A 

X 

B 

c 

1.5  mile 

D 

less  than  1  mile 

E 

1  mile 

F 

1  mile 

4.  Did  this  demonstration  verify  that  you  were  able  to  meet  or  exceed  operational  separation 
requirements? 


Controller 

Yes 

No 

Not  Observed 

Comments 

A 

X 

B 

X 

c 

X 

D 

X 

E 

X 

F 

X 

BTP  CODE  VALIDATION  AND  ACCURACY 


1 .  Did  you  always  observe  a  correct  response  when  a  target  squawked  ident? 


Controller 

■  Yek"' t 

. . . 

Not  Observed 

•Cohimeiits 

A 

X 

B 

X 

c 

X 

D 

X 

E 

X 

F 

X 

2.  Did  you  observe  the  correct  beacon  code  for  each  target  displayed? 


Controller 

..Yes  ::: 

No 

Not  Observed 

Comments 

A 

X 

B 

X 

c 

X 

D 

X 

E 

X 

F 

X 
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3.  Did  you  observe  any  incorrect  responses  when  a  target  squawked  ident? 


Controller 

.  :.  Yes  "  ; 

No 

Not  Observed 

Comments 

A 

X 

B 

X 

C 

X 

D 

X 

E 

X 

F 

X 

4.  Did  you  observe  any  incorrect  beacon  codes  for  the  targets  displayed? 


Controller 

Yes 

No 

Not  Observed 

Coimnents 

A 

X 

B 

X 

C 

X 

D 

X 

E 

X 

F 

X 
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BTP  SPLIT  AND  FALSE  REPORTS 

1 .  Did  you  observe  any  beacon  splits  during  this  demonstration? 


Controller 

No 

Not  Observed 

Comments 

A 

X 

B 

X 

C 

X 

D 

X 

Four 

E 

X 

F 

X 

0 

X 

six  ox  seven 

H 

X 

I 

X 

tltree 

F 

X 

1 

Iliiiil 

twenty 

K 

X 

L 

X 

M 

X 

N 

X 

one  -  20  miles  east  of  blh 
on  tire  083  radial  1  observed 
one  split  beacon.  The 

number  of  beacon  splits  would  be  acceptable  to  me 

as 

a  controller.  I  ob^rved 
what  seemed  to  be  fewer 
beacon  splits  and  track 
jumps  than  tvhal  is  normal. 

O 

X 

Ihirteen 

P 

X 

Q 

X 

Nine 

M 

X 

R 

X 
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2.  Did  you  observe  any  false  beacon  reports? 


Yes 

No 

Not  Observed 

Comments 

A 

X 

B 

X 

c 

X 

D 

X 

E 

X 

F 

X 

X 

Tliree  or  four 

H 

X 

I 

X 

F 

•X  - . 

One 

•  Jv  •-  ’  J;"  ‘  • 

.  3C  ' 

M 

X 

Seven 

o 

X 

p 

X 

Q 

X 

M 

.X 

Twenty  Five 

"  x" 
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WEATHER  DETECTION  AND  PROCESSING 


1 .  Did  you  observe  the  two  levels  of  weather  information? 


Gontrdller 

■■"Yes  ■■; 

No  : 

NotObserved 

Gomments 

A 

X 

B 

X 

C 

X 

D 

X 

E 

X 

F 

X 

G 

....  X 

But  they  were  false 

H 

I 

"  '-x- 

F 

X 

1 

But  I  did  deserve  a  single 

line  of  weather  without  the 

HHH  or  other  symbols. 

K 

X 

'  k 

X  -i 

■■■■ 

X  -1 

o 

iiiiiiii 

Q 

iiliiii 

■■k-'vV-.vy. .  X  1 

M 

X 

R  ■ 

;  X  I 

Eftonemis  BOfUt  ofBZA 

2.  Were  you  able  to  distinguish  between  the  different  levels? 


Controller 

slYelkk' 

No 

Not  Observed 

Comments 

A 

X 

B 

X 

C 

X 

D 

X 

E 

X 

F 

X 

G 

iiiiiiii 

But  they  were  false 

..H 

X 

I 

iiiii 

v'iv  ia;-'..  s 

}.■■■■ 

■  X 

X 

.-  M 

iiliiii 

N 

■x  . 

o 

iiiiiiii 

p 

■Q--  ■ 

iiiii 

■  ■  M  ■ 

iiiii 

R 

iiiii 
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3.  Was  the  weather  contour  well  defined? 
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